Build: 2000090820, Mac OS 9.0 PowerPC 7300/180, 48 Mb RAM No other applications running (except BBEdit Lite, which hardly counts because it's using a whopping 798 kb RAM) Steps to reproduce: * Start Mozilla. * Select `Edit' > `Preferences ...'. What was expected: * The Preferences dialog should open within one second. If this is not possible, a busy cursor should be displayed so that the user knows something is happening. What happened: * The Preferences window opens after 26 seconds, with no user feedback. For most of those 26 seconds, Mozilla appears to have hung. The reason I've put this in XPToolkit/Widgets is that this should happen whenever *any* window is opened. If you know that it's more than one second since the application asked for the window to be opened, and you still haven't got it open, you should put up a busy cursor. That will keep the user from panicking -- for at least another ten seconds, anyway. References: * `Busy cursor' <http://www.quinn.echidna.id.au/Quinn/WWW/HISubtleties/BusyCursor.html> * `Response Times: The Three Important Limits' <http://www.useit.com/papers/responsetime.html>.

->pinkerton, adding bug 49141 (new window perf) to blockee list, since I think a fix for this bug should probably be part of a 6.0 solution to 49141.

A busy cursor should appear right away or not at all. Less confusing that way. If I do something and the feedback isn't until later, then I'll end up wondering what I did that caused the cursor to change to a busy cursor.

we're going to use a solution pioneered by macApp, whereby if control is not returned to the main event loop (or a surrogate event loop, say for dialogs) for a second or more, we automatically switch to the busy cursor. this should catch both window opening and the times where layout locks up the machine loading CNN. how does that sound? we can play with the timing to get it right.

Sounds OK, I guess. But I'd like to see it more immediate.

Busy cursors are recommended by Jakob Nielsen for delays of 2-10 seconds, although he seems to be okay with some feedback for tasks that take only 1 second. In any case, having the latency be tunable will be great.

Right. If the delay is expected to be less than one to two seconds, a busy cursor is not needed. If the delay is expected to be between two to ten seconds, throw up a cursor right away. If the delay is expected to be more than ten seconds, use a progress indicator of some sort. That's one side, when we can estimate the delay. Then there's the other side where an expected short delay (one to two seconds) turns out to be a long delay. Say something that That's when we should start out without a busy cursor, then throw one up after the pre-defined delay elapses.

Yes, right away if possible, or after the latency when things unexpectedly take longer. I think what you describe is the technique they plan to use.

i have the code written, but it's mac only. i'm only going to do mac so pbbbht. who wants to own this for other platforms? I've also disabled that stupid beachball cursor on mac only, because the new way is much nicer (and spins the watch instead).

fixed on mac, my work is done here. open a new bug for linux/win32.

> i have the code written, but it's mac only. i'm only going to do mac so pbbbht. Riiiiiight. I'm sure jrgm will be glad at having to file separate bugs for every other platform. For beach ball problems, see bug 49173.

Changing platform and os to something apple-like.

The patch to navigator.js to disable the busy cursor on the Mac actually disabled it on ALL platforms. (the JS platform check is wrong) Nonetheless, this sad, half-complete JS hack I introduced should probably be removed anyway on all platforms and replaced with a fix for Bug 30375... and Bug 49173, and Bug 48839 to change the semi-busy cursors for Mac and Unix. I'd also like to see the Windows equivalent for this bug as well (hourglass during layout lockup and window load).

Nah, reopening. Pink, this is bad bad bad. Back it out. Your fix only works on one platform, and even on that platform it has major bugs. Build 2000091920, Mac OS 9.0: * The cursor vacillates between pointer and spinning watch, giving the impression of an app which can't make up its mind. For example, I count the spinning watch turned on and off eleven times during startup, and twice during the opening of any dialog (e.g. the Password Manager). It should just happen once. * More seriously, when I open any native dialog from Mozilla -- including File Open and File Save (and also external utilities such as FlashIt, which I use to take screenshots of Mozilla) -- the cursor flickers between pointer and spinning watch, when it should just be the pointer all the time.

Try again with a build after last night (today if you can get one to run). Mike check in a few lines to suspend this behaviour when opening a dialog, and when doing a drag. If there are other cases still incorrectly firing, reopen for those points (and I will see how things look in today's build which I hope will run...).

Well, actually there is another code path to cover: the watch cursor flickers on and off when you have the filepicker native dialog up. (The print dialog and the drag session don't have problems anymore). And the watch cursor also goes off and on during startup of the app (probably best to suppress it, at least during component reg.). But this is being tracked as nsbeta3+ bug 53121. I will note these there.