The 'busy' cursor uses the 'reload' icon instead of the usual watch icon. I'm using a slightly hacked version of the classic skin, this might be of inclusence (not the slight hack, but the classic skin).

I'm seeing this on Linux 2000-08-12 builds. After typing a URL in the Location bar, the mouse pointer changes to the two-arrows-chasing-each-other.

asa - build ocnfig perhaps or event handling?

*** Bug 49173 has been marked as a duplicate of this bug. ***

No, this is the result of bug 30375 being "fixed". However, the "reload" cursor that is used isn't very pleasing to the eye, and unexpected on MacOS as well. The cursor looks jagged. In the animated version one see of it while ftp folders open there are better "samples" which could have been used, it looks "rounder" while it spins. But a non-spinning version doesn't look good either way :/ Marking 49173 dup of this, but again: the "original sinner" is 30375

GUI feature.

added dependency.

Resummarizing. (See also bug 49173.) The `spinning' cursor is used where the program is busy, but where user input is still possible. So the cursor should be a pointer (to show the possibility of user input), next to a miniature of what the `wait' cursor normally looks like (to show the busy-ness).

nav triage team: reassigning to Matt, assuming this is an easy fix. If it is a problem, we will minus it. nsbeta3+

isn't this something more appropriate for ben to fix? if not, ben feel free to bounce it back to matt.

We thought maybe Matt could handle it (I know he was doing some work on the busy cursor). But I'll leave it with Ben unless he can get Matt to take it. Making P1 in any case.

I'm not familiar with cursor implementation on linux, but if this is indeed the wait-cursor, then this is more a toolkit issue than a xpapps one. We just use what wait cursor we're given.

reassigning to pavlov as nsbeta3+, P3 for M18

fixed

i marked bug 49173 a dup of this one - it is reported on MacOS 8.6 however. Is that fixed too or should i reopen it?

rkaa, they're treating this one separately since it's on a different platform (yeah, go figger --prolly since the fix is different enough :-). in any case, this is fixed in the sense that i now get the clock icon instead of the reload icon. so i'll verify for that fix [2000.08.22.08, comm linux].

Nyet. The `spinning' cursor should be different from the `wait' cursor, in that `spinning' should make it obvious that even though Mozilla is busy, you can still do stuff in the app (whereas `wait' is used in situations where you can't do stuff in the app). If this is not the case (and IIRC from my Unix days, a clock cursor is used in `wait' situations, rather than `spinning' situations), then please reopen this. (BTW, Ian Hickson and I discussed this, and he's going to suggest to the W3C that they come up with a more appropriate name than `spinning' for the partly-busy cursor.)

okay, i'm getting a bit confused as to what i should see for the various cursor icons... if the 'wait' cursor should be the clock icon, what should the 'spinning' icon appear as? for some silly reason i cannot remember what the 'spinning' icon should look like. so, if the spinning icon, should *not* be the clock face (as what i'm seeing here), since that should be for the wait icon...then i oughtta reopen this, yes? thx in advance for further clarification. :)

ah, skimmed over bug 49173: so perhaps the spinning icon should be the unix equivalent of a pointer+hourglass (win32) or pointer+beachball: ie, a pointer+clock?

You got it, Sarah. So on X, `normal' = pointer, `wait' = clock, and `spinning' = pointer + miniature clock.

thx, mpt. in which case... i can either (1) reopen this since we're now showing the 'wait' icon, or (2) file another bug to further fix this so that we do show the clock+pointer icon for 'spinning'. i don't care either way --any preferences?

From a comment in the source it sounds like we're limited to these cursors for now. http://www.tronche.com/gui/x/xlib/appendix/b/ Apparently you can create custom cursors in Unix, but this isn't implemented in Mozilla at all. Not sure how difficult it would be.

its simply a matter of you giving me a bitmap (xbm) cursor

Ok, I can draw one. Just let me know: which cursor is Mozilla using for `normal'? Is it XC_top_left_arrow (which looks familiar from my Solaris days), or is it XC_left_ptr?

xc_left_ptr is what you want

Attached arrow-and-watch combo, based on XC_left_ptr and XC_watch from <http://tronche.com/gui/x/xlib/appendix/b/>, in GIF format. Sorry I have nothing here which writes XBM (I seem to recall that XBM is just lisp-ized ASCII art, but I don't have an XBM file to look at).

P5

Mass-moving P4/P5 bugs to Future milestone. We just don't have any time left for these, although we could still consider taking a good patch. Adding Helpwanted keyword.

nsbeta3-

I like mpt's busywait cursor. Using in bug 38444. Thanks :)

Adding qawanted; could use a testcase.

To whom it may concern: It has come to my attention that the cursor I drew in attachment 13727 [details] has become the semi-standard X11 semi-busy cursor -- so much so that some software themes the cursor by looking for my exact collection of bits. Therefore, any application that wants its semi-busy cursor to follow the theme of the rest of the system has to use my exact collection of bits. Therefore, in the interests of X11 interface consistency, I am hereby putting attachment 13727 [details] not just under Mozilla's GPL+LGPL+MPL combo, but also in the public domain. Anyone may use it for any purpose.

WFM, 2004-07-26-07 trunk Linux (SuSE 9.0/KDE 3.1 if that matters). Both CSS2.1 'progress' and vendor specific '-moz-spinning' shows the symbol in attachment 13727 [details]

WFM, 2004-08-06-07 trunk Windows XP WFM, 2004-08-07-06 trunk Linux -> WORKSFORME