This is for bugzilla bug 1785. Rick already has a patch to fix this bug at: http://bugzilla.mozilla.org/showattachment.cgi?attach_id=47043

Fix in hand.

I've attached a better version of the patch. Basically, the patch adds an argument to nsIDocument::FlushPendingNotifications(...) indicating whether views should be synchronously updated too... The bulk of the changes are to the call sites of FlushPendingNotifications :-) This patch causes *all* nsIWebBrowserChrome::setStatus(...) messages to be displayed synchronously. However, this is not as bad as it sounds! It looks like many status messages from mozilla are actually displayed via nsBrowserStatusHandler.js which bypasses this mechanism :-) -- rick

just waiting for reviews...

r=valeski

sr=vidur I wonder if the junk around the nsSplitterFrame change could be replaced with a shell->FlushPendingNotifications(PR_TRUE);. Not required for the checkin, though.

Rick, what happened to STATUS_FLAG_SYNC?

Never mind. I see now that it isn't needed since all setStatus calls are synchronous.

yeah... i decided that from a usage standpoint ALL callers of setStatus(...) really expected the results to be displayed synchronously... The whole 'async nightmare' is really just an artifact of how mozilla implements its status bar...

I've just checked this patch in...

Any reason this was checked in on a closed (for verifications, not for drivers-approved checkins) tree, without drivers approval?

yep... i didn't notice that the tree was closed for verifications :-( sorry...

What about the drivers approval half? (I probably should've backed out your checkin earlier just because of that, but I have other things to do.)

I'm preparing a backout of these changes because they were checked in without drivers approval, and I suspect that if you had asked for approval we would have asked you to wait until 0.9.5. If you do want to check them in for 0.9.4, as it says on the top of tinderbox: Please mail approval requests to drivers@mozilla.org and help us not be the bottleneck by including an explanation of the risk and any testing associated with your fix. I'm also a little concerned about the perfomance effects of doing an immediate refresh, and also whether doing an immediate refresh could push us into code that we shouldn't be in at a certain point. I'm not an expert on these things, but it would be nice to whether you'd checked page loading performance, etc., before approving the patch.

Backed out.

-> dbaron since you don't feel that this is *really* a 0.9.4 bug. why don't you check the code in when you believe that mozilla IS ready

Whatever. Un-backed-out.

As i stated earlier, the perfomance impact of this change should be minimal. During 'normal' page loads (ie. those that do not set the status via javascript) this code is called *twice*. Both times from nsGlobalWindow::SetNewDocument(...). All other status messages are posted out-of-band and are not effected by this change. The other side effect of this patch is to fix the semantics of setting the status from javascript. In both Nav 4.x and IE setting status from javascript occurs synchronously. This patch allows mozilla to do the same. There may be performance issues if a particular javascript starts spamming status messages... this should be addressed if it turns out to be a real problem... == rick

Wow, Rick, Dave, I didn't mean to create a hot potato. Dave, the reason these changes were important was for bug 97380, which I believe is very important for eMojo. 97380 posts a "Starting Java..." type message to the status bar when the time comes to start up java (and totally freeze the browser for about 10 seconds). I'm waiting for sr= someone before asking for drivers about it.

after a long night. closing. blizzard wound up approving this bug for 0.9.4 checkin.

marking VERIFIED Fixed