Boris Zbarsky <[EMAIL PROTECTED]> wrote: > Ben Hutchings wrote: >> Surely I'd need to find the document first, and that's not possible >> until it has at least started loading, which I would detect in the >> same way. > > Fair enough. You can actually set the load handler on the window, but given > that you're doing things after onload that doesn't matter anyway.
I see. >> // TODO: Check whether this is actually important. >> pres_shell->FlushPendingNotifications(true); >> >> // The change of state may trigger image loads, >> // which complete asynchronously. If so, wait >> // for them to finish. >> while (pending_req_count_ != 0) >> Gtk::Main::iteration(); >> >> // here I copy changes to the link area (link_rect) >> // into a pixmap > > Ah, I see. So at the very least, when the image load completes we post an > event > to do the actual painting. It looks like that event won't get processed > before > you copy things to the pixmap. I don't believe that's the problem. > Does moving the FlushPendingNotifications(PR_TRUE) to after the while loop > help? > I suspect it should... As it is, the loop never exits. My actual code for on_net_state_change includes some output statments which report its arguments. They show that it is never called with the REQUEST and STOP flags. If I remove the loop, it is called with these flags during the next call to DispatchEvent. -- Ben Hutchings Never attribute to conspiracy what can adequately be explained by stupidity. _______________________________________________ mozilla-embedding mailing list mozilla-embedding@mozilla.org http://mail.mozilla.org/listinfo/mozilla-embedding
