52108 - Show busy cursor while opening a new window

Status: VERIFIED FIXED

(Core :: XUL, defect, P3)

Description

[Matthew T (active 1999-2002)]

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>.

Comment 1

[Peter Trudelle]

->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.

Comment 2

[:deanis74]

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.

Comment 3

[Mike Pinkerton (not reading bugmail)]

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.

Comment 4

[:deanis74]

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

Comment 5

[Peter Trudelle]

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.  

Comment 6

[:deanis74]

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.

Comment 7

[Peter Trudelle]

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.

Comment 8

[Mike Pinkerton (not reading bugmail)]

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).

Comment 9

[Mike Pinkerton (not reading bugmail)]

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

Comment 10

[Matthew T (active 1999-2002)]

> 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.

Comment 11

[:deanis74]

Changing platform and os to something apple-like.

Comment 12

[Tim Hill]

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).

Comment 13

[Matthew T (active 1999-2002)]

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.

Comment 14

[John Morrison]

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...).

Comment 15

[John Morrison]

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.