over to jst for a look.
We can't fix this in mozilla, the reason this works in 4.x is that JS runs on its own thread so the UI stays responsive while JS loops run but in mozilla JS runs on the main thread which makes any JS block the main thread untill the JS is done, because of this mozilla never has a chance to draw/paint the new status message while the JS loop is running. WONTFIX.
Moving the execution of JS in web pages from the main thread is something that should've been done from the beginning in mozilla if it's something that was ever gonna be done, putting JS on the main thread was a design decition that was made early on to avoid all the nasty thread synchronization stuff that went on in 4.x. Changing this is not something that can be done just like that, if it's done it means that everything that JS can and will call must be thread safe, that includes the whole DOM and everthing that the internal DOM code relies on. This just won't happen any time soon if ever, and there's not a really good reason for doing it either. If we wanna redesign things from the bottom up then fine, we could move JS off the main thread but changing the way mozilla executes JS today won't change any time soon. Won't fix.
I agree that we shouldn't move JS out of the main thread any time soon. However, can we make this looping testcase behave better? Is there a way to synchronously update the status bar and repaint from within the native setter for window.status? Can the branch callback help (for this loop, it will do a JS_MaybeGC once at the 4096th iteration)? /be
We let non-modal windows re-paint while a modal window is flying, right? That gives me hope that we can do something for the particular problem described in this bug's Summary. /be
> there's not a really good reason for doing it either. IMO, this bug is a very good reason. <rant> I find it disappointing that Mozilla such problems. </rant>
BenB: your rants need more humor and bitterness -- "I find it disappointing..." is on the order of "Dear Sir / You Cur" ;-) What does Opera do? Anyone have other browsers that handle JS to try? We can reopen this if someone shows a good way to pump certain events (similar to those that get serviced on other windows when a modal window is flying) from the branch callback, and maybe make the status bar painting synchronous, at least when the status bar is updated directly from JS. /be
> your rants need more humor and bitterness That's probably, because it wasn't really a rant - I'm not bitter in this regard yet. That's probably because I'm not sure about the scope of this bug. What I do see all the time and am seriously worried about is the flakyness of the UI, which seems to me being caused by lack of threadiness. E.g. I open the (large) bookmarks menu, and you can see all of the UI - throbber, caret etc. - suddenly stalling until the menu opened. And this is not even to start with different top-level windows stalling each other. E.g. while I resort the thread pane or open a new browser window, the whole application is completely unusable - everything just stops until (most of) the action is completed. I hoped that this is just because Mozilla is still immature and it will be fixed over time. But I can't understand why you would design a app in 1998/99 without making it completely threaded. Sure it's more work, but users can see the result - it gives a smoother app. And it excludes problems like this bug. Back obtopic, it I'm right with my assumption above and the problem in this bug has the same cause as the problems I described, then we should IMO fix the threading. If it's a redesign, then for 2.0. (IMO, "n.0" should imply redesign anyway :) .)
Could this bug maybe be fixed without changing threads? Bug 30942 suggests to insert calls to the event loop in central places of JS execution. This would ensure drawing of windows, not?