49173 - [Mac] `spinning' cursor should be pointer + spinning ball

Status: VERIFIED FIXED

(SeaMonkey :: UI Design, defect, P2)

Description

[gsa]

mac build id: 2000081504
when the browser is busy the cursor changes into a black and white
wheel. in previous builds the cursor would remain as a black arrow.

Comment 1

[R.K.Aa.]

related to bug 30375 where a "wait" cursor while page loads is requested.
In windows the hourglass+arrow is the wait-cursor. But for users on linux and
macOS it seems the "loading" cursor is an unexpected choise (and i find it plain
ugly as well).

bug 48839 was filed about this regarding linux. Marking this dup of it.

*** This bug has been marked as a duplicate of 48839 ***

Comment 2

[Matthew T (active 1999-2002)]

Reopening and resummarizing. This needs to be fixed separately on Mac and X.

The problem is that CSS3 defines two cursors for busy state: `wait' and 
`spinning'. `wait' is for when the program is busy, and the user must wait. 
`spinning' is for when the program is busy, but the user may still do other 
stuff.

The CSS3 draft states that `spinning' is `often rendered as a spinning beach 
ball'. This seems to be incorrect: I have only ever seen a spinning beach ball 
cursor on Mac OS, in the `wait' situation. Better for `spinning' would be an 
arrow with a small spinning ball alongside it, equivalent to the pointer-plus-
-hourglass combo used on Windows. (I have seen such a cursor used before, but I 
can't remember where.)

So this needs to be fixed, but I haven't got a clue which component it would go 
in. Doron? Asa?

Comment 3

[Doron Rosenberg (IBM)]

over to xpa gui, ben and sairuh. Not sure though if this is ben.

Comment 4

[sairuh (rarely reading bugmail)]

need to fix this, so nominating for beta3.

Comment 5

[johng]

nav triage team:
nsbeta3+
reassigning to matt since he is dealing with other cursor problems.  Also, Matt 
you may want to talk with German - MPT seems to be right, but we don't think we 
are consistent in the app.

Comment 6

[Bill Law]

Marking P1.

Comment 7

[Tim Hill]

Does anyone have a resource file for the arrow/ball combination?  Is this a 
built-in cursor on the Mac? (I'd help, but I'm a Windows person.  If someone 
wants to send me a free iMac or G4 Cube... :) )  Is this the kind of cursor 
you're looking for (except reversed): 
http://207.208.148.74/user_contributions/cursors_lefty.gif

Comment 8

[matt]

The ball should happen when you can click on something
else but you should wait.
The hour glass appears when you can't click on anything.
Looks like pierre did changed this on bug 38445.
Flipping to him.  Also the cursor when a page is loading is calling
spinning so we get the circle.  We should be loading the hour glass and
if we switched spinning to the hourglass:
  
case eCursor_spinning:   cursor = kThemeWatchCursor; 

it would fix this problem.
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/widget/src/mac/nsWindow.cpp

Comment 9

[Pierre Saslawsky]

This is wrong. Per the Macintosh HI Guidelines, both cursors can be used 
indifferently (http://developer.apple.com/techpubs/mac/IAC/IAC-476.html). In some 
applications, they still allow you to click a Cancel button in a modal progress 
dialog or a Stop button somewhere in the UI, but they usually don't allow you to 
select anything in the menus for instance.

Closed as invalid. Many applications work the same (ahem.. MacIE5 for instance).

Comment 10

[Matthew T (active 1999-2002)]

Reopening, again. Pierre, please see my 2000-08-16 comment. The W3C have 
incorrectly called this cursor `spinning', and they have incorrectly stated that 
it's often shown as a beach ball. (Ian Hickson is going to have a word with them 
about that.)

But the intent of the cursor is clear; to show that while the area is busy, it 
can still accept user input. It seems the built-in Macintosh cursors were 
designed before there were apps sophisticated enough to have such a state in a 
single window, and `semi-busy' isn't allowed for in
<http://developer.apple.com/techpubs/carbon/HumanInterfaceToolbox/AppManager/
Appearance_Manager/Enumerations/Theme_Cursor_Constants.html>.

What we are looking for here is the counterpart to Windows' pointer+hourglass. 
It's not the wristwatch, and it's not the beach ball. It's the pointer+beachball. 
So this is only invalid if drawing our own semi-busy cursor would be a Really Bad 
Thing to do. And I don't think it would be -- especially if it's going to give us 
better UI feedback, and better CSS support, than IE 5. :-)

Comment 11

[Pierre Saslawsky]

I did not hear from Ian on that topic. Your interpretation is debatable: maybe 
we'll keep 'spinning' for the beach ball and add a new value ('wait-and-click'?) 
for the Win32 cursor you are talking about. I don't believe that moving Win32 
interface elements to the Macintosh makes a better CSS support.

Another question is: do we want to let the user click on anything while the page 
is loading? That could be a problem with forms, for instance. Or do we enable 
only the toolbar buttons? In that case, the spinning cursor is appropriate.

Comment 12

[Matthew T (active 1999-2002)]

> maybe we'll keep 'spinning' for the beach ball

In which case it would be semantically indistinguishable from `wait' (because 
that is what the beach ball is predominantly used for), so there wouldn't be any 
point in including it in CSS in the first place.

Remember, loading a page is just one use of the `spinning' cursor. 4.x on Mac 
uses `normal' (an ordinary arrow) in the loading-page situation, so if you are 
dead-set against the idea of using a custom cursor for CSS `spinning', you could 
just say that for Mac, `spinning' == `normal'.

> do we want to let the user click on anything while the page is loading? That
> could be a problem with forms, for instance.

Every previous version of Mozilla has allowed you to do this -- it's one of the 
benefits of incremental rendering. But that's why I suggest that `spinning'
*should* be a different cursor from `normal' -- as a subtle warning to the user 
that form elements, links etc may shift from under the cursor, so that the user 
should only interact with them if their position seems stable.

>                                              Or do we enable only the toolbar
> buttons?

Chrome is subject to the same uncertain state as content. Two examples: (1) The 
`Forward' button will be disabled (if it was enabled before). (2) Scrollbars may 
appear/disappear. But that's no reason to lock up the GUI, as you would *appear* 
to be doing if you used a beach ball for `spinning'.

Comment 13

[Pierre Saslawsky]

The current behavior is consistent with the spec and with the best of what the 
competition has to offer. I understand your request for a change in the 
specification to adopt a Win32 cursor rather than a Macintosh cursor, I don't 
have any strong opinion on that matter, however I'm opposed to making 
`spinning' == `normal', that would clearly be an error.

Maybe the problem lies in the chrome rather than in the spec. The spinning 
cursor, regardless of what it looks like, should not be set over the chrome but 
only over the content area while a page is loading. I opened bug 50604.

Comment 14

[Hixie (not reading bugmail)]

mpt wrote:
> The W3C have incorrectly called this cursor `spinning', and they have 
> incorrectly stated that it's often shown as a beach ball. (Ian Hickson is 
> going to have a word with them about that.)

mpt: FYI - 'them' in that last sentence includes both Pierre and me.

Pierre: I'm still trying to work out what to bring forward to the WG. There
appears to me to be four cursors here:
 1. ready
 2. busy but only for this part of the chrome
 3. ready but working in the background
 4. busy

On windows, 2 is represented with the same cursor as 4. On the Mac, there is 
no equivalent to 3. AFAICT. I'm still investigating.

Comment 15

[Tim Hill]

If CSS isn't going to change, I can always disable (IFDEF XP_MAC) the busy 
cursor behavior in my C++ patch for Bug 30375 (for network load, during page 
load, or both).  The point is, we want to provide more useful cursor feedback 
on each platform than currently exists, or even no feedback at all (as it is 
now), but definitely not misleading or worse feedback.  As for not showing the 
cursor in chrome, I disagree.  I find this useful in Windows (IE 5 does it), so 
the spinning cursor displays when I click Back/Forward/Reload.  But then again, 
the Windows arrow/hourglass cursor very clearly communicates that you can still 
click on something compared to its counterparts on other platforms.

Comment 16

[Pierre Saslawsky]

Ian: I propose the following cursors instead:
1. ready
2. wait
3. spinning (same thing as 'wait', just a different look)
4. spinning-pointer (the "arrow + watch" Win32 cursor)

With my Macintosh background, I'd say that:
- 'ready' should be used all the time over the chrome.
- 'wait' or 'spinning' should be used during synchronous operations that may take 
a certain time (startup, view source, load mail folder...).
- 'spinning-pointer' should be used over the content area while loading a page.

I understand from Tim that to accomodate certain low-level considerations, we may 
have to display the 'spinning-pointer' over the entire window (content + chrome) 
while a page is loading. Win32 users seem to like it. Mac users can certainly 
live with it for now (if they don't, we'll file a bug that will be Future'd). 
Unix users, I guess, won't have any opinion.

When contacting the WG, you can present the solution above (make 'spinning' an 
equivalent of 'wait', and add 'spinning-pointer'). In case of problem, we can 
implement a '-moz-spinning-pointer'.

I'm a little bit opposed to a solution where we would change the 'spinning' 
cursor to make it look like a spinning-pointer because we would lose the "real" 
spinning look, and I am very much opposed to adding some #ifdef XP_MAC, or making 
the 'spinning' cursor display like an arrow.

Comment 17

[Matthew T (active 1999-2002)]

Ian: check your e-mail. :-)

> The current behavior is consistent with the spec

It is, quite literally, consistent with the spec in name but not in spirit. That 
is, we're choosing our `spinning' cursor based on the name of the cursor, rather 
than its stated intent in the spec.

> I understand your request for a change in the specification to adopt a Win32
> cursor rather than a Macintosh cursor

I'm not suggesting the adoption of a Win32 cursor. I'm suggesting that `spinning' 
be renamed to `working', which is less implementation-specific and more 
accurately reflects the stated meaning of the cursor. And I'm suggesting that for 
`working' (or `spinning' as we are calling it right now), we use a custom cursor 
which looks how an Apple-supplied `working' cursor would, if it existed, which it 
doesn't.

> Ian: I propose the following cursors instead:
>...
> 3. spinning (same thing as 'wait', just a different look)

But surely, these OS-agnostic CSS cursor names are meant to be interpreted by the 
OS (and the user settings) with a cursor of a given look -- they are not meant to 
define the look of the cursor itself. That's why they say that such-and-such a 
cursor `is often' shown as whatever, instead of `should be' shown as whatever.

If you really want a CSS cursor name for your beloved beachball, it should be 
`wait-long'. For when user interaction is not possible (like `wait'), but the 
wait is longer than in situations where just `wait' would be used, so more 
animated feedback is required. (The Windows equivalent would be the hourglass 
which repeatedly trickles sand and then rolls over, as opposed to the hourglass 
used for `wait' which just stands still.)

Anyhoo. I'm about to attach four transparent GIFs which Pierre or whoever can 
convert into CURS resources to assemble a `spinning' cursor to fix this bug. I 
can't tell from Apple's documentation whether the white outline around cursors is 
part of the cursor, or whether it's added by Mac OS; I'm guessing the latter. If 
it's the former, let me know and I'll add the outline and attach revised 
versions.

Comment 18

[Matthew T (active 1999-2002)]

Attachment: working-1.gif -- frame 1 for `spinning' cursor

Comment 19

[Matthew T (active 1999-2002)]

Attachment: working-2.gif -- frame 2 for `spinning' cursor

Comment 20

[Matthew T (active 1999-2002)]

Attachment: working-3.gif -- frame 3 for `spinning' cursor

Comment 21

[Matthew T (active 1999-2002)]

Attachment: working-4.gif -- frame 4 for `spinning' cursor

Comment 22

[Tim Hill]

If "spinning-pointer" gets added to the CSS spec (or -moz-spinning-pointer), 
and each platform adds a spinning-arrow cursor, I could use it in the busy 
cursor code, and this would fix the problem.

My C++ patch doesn't differentiate between chrome and content.  A busy state in 
one of the content areas makes the parent chrome area busy as well.  This is 
nice because it provides busy cursor feedback not just for the browser window, 
but in every place where content is loaded; initializing a chrome window, 
switching between Preference panes, loading in the sidebar, etc.

Comment 23

[Tim Hill]

Should this really be called "spinning-pointer"?  "pointer" by itself in CSS2 
is actually the hand cursor used over links, not an arrow.

Comment 24

[Pierre Saslawsky]

Tim: correct, 'spinning-arrow' is more exact and it sounds good too.

Matthew: I don't have any beloved cursor. I just work here.

Comment 25

[Matthew T (active 1999-2002)]

But `spinning-arrow' is sooooo implementation-specific. IMO, CSS cursor names 
should denote states, not looks, and it should be up to the platform to decide 
what they look like.

Anyhow, right now we need a cursor for page loading which looks more 
interactive than the beachball, CSS3 `spinning' is available, we support it in 
the back end right now, and I've attached Mac-looking graphics for such a 
cursor. Can this be fixed now? Yes? No?

Comment 26

[Phil Peterson]

PDT moving to P3 and leaving [PDTP3] breadcrumb in status whiteboard

Comment 27

[bugzilla]

As a semi-impartial Mac user, I'd like to throw in my two cents and say I think 
Matthew's new arrow+spinner cursor would be pretty intuitive to most mac people-- 
ie, "oh, it's doing something, but I can click anyway."  I was a bit confused 
with recent builds when I had the spinning beachball but realized I could click 
anyway.

I wonder if it'll look weird on OS X (beta's out in 8 days), but then I don't 
know what kind of cursor conventions Aqua has ;)

W

Comment 28

[Matthew T (active 1999-2002)]

> Better for `spinning' would be an arrow with a small spinning ball alongside
> it, equivalent to the pointer-plus-hourglass combo used on Windows. (I have
> seen such a cursor used before, but I can't remember where.)

I just rediscovered it ...

... It's the cursor iCab uses when it's loading a Web page. :-)

Comment 29

[Tim Hill]

This doesn't really have to wait on the working group.  I could simply add a 
cursor constant for arrow/spinning only accessible on the back-end, and use 
this constant in the patch for Bug 30375.  I could also implement it on 
Windows, however someone else would need to fully implement it on Mac and 
Linux.  Either way I'd like to get this working for Windows.

Comment 30

[karnaze (gone)]

Changing to nsbeta3-.

Comment 31

[Pierre Saslawsky]

Block moved M18 bugs to mozilla0.9.1

Comment 32

[Matthew T (active 1999-2002)]

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

Comment 33

[Andrew Thompson]

(coming in from the duplicate)

Well I like mpt's cursor. Says what we want it to say. And I dislike using the 
beachball... the beachball pretty much means "this application is busy and you 
can't interact with it" whereas the wristwatch means "the system as a whole is 
busy and you can't interact with it". (not that this has ever really been used 
consistently)

What's the issue here? Making curs and/or accr resources out of these GIFs is 
literally about 20 minutes work, but it sounds like Tim has some C++ that's 
needed too? 

Comment 34

[Matthew T (active 1999-2002)]

Since bug 30375 has been fixed, I don't think any C++ code is needed here at all. 
So yes, it should be just 20 minutes work. :-)

Comment 35

[Andrew Thompson]

Attachment: Existing Mozilla Arrow + Wait cursor

Comment 36

[Andrew Thompson]

Found this cursor is already in Mozilla. It'll be used for the "spinning" cursor 
if we're running on a system where the Apperance Manager is not available. This 
effectively means "never" since we support only OS 8.5 or greater and will soon 
be going Carbon.

I can make a 1 line code change to have this cursor used, or I can make a cursor 
based on Matthew's design and use that.... Thought?

BTW - Mozilla doesn't seem to be using animated cursors at all. These actually 
aren't a simple drop in replacement on Classic Mac OS (dunno about OS X). If look 
at the beachball currently in use, it never spins. 

Comment 37

[timeless]

that's funny.

Comment 38

[Andrew Thompson]

no, what's really funny is that System 6 used to so animated cursors better - the 
watch used to be spun by the system for you. I believe this is true of the 
newfangled shiny coloured beach ball on OS X also. Progress huh?

Are we to take it you don't care which design it used ;-P ?

Comment 39

[timeless]

i'm a system6 lover. but i'm not your typical mac user.

Comment 40

[Matthew T (active 1999-2002)]

Well, I prefer my one. :-) I think my mini-beachball resembles the full beachball 
more closely than that mini-watch resembles the full watch. And if what you say 
about the difference between the watch and the beachball is correct, the 
beachball more closely matches what we mean (app is busy) than the watch does 
(system is busy).

<offtopic>
> System 6 used to so animated cursors better - the watch used to be spun by the
> system for you. [...] Progress huh?

I think that was changed to improve the UI, actually. :-) If the application is 
forced to animate the cursor itself, then if the app crashes the user will 
realize this because the cursor stops animating. If the system animates the 
cursor itself, then the user might sit staring at an animated cursor for ages not 
realizing that the app has gone kaput.
</offtopic>

Comment 41

[Andrew Thompson]

Attachment: Patch to nsWindow.cpp to enable Mozilla's spinning cursor rather than using Apperance one

Comment 42

[Andrew Thompson]

Attachment: Ooops. This is the right patch!

Comment 43

[Andrew Thompson]

Attachment: Patch to widget/src/mac/nsMacWidget.rsrc to change cursor to Matthew's design (this attachment is MacBinary encoded)

Comment 44

[Andrew Thompson]

You can apply either just the patch to nsWindow.cpp, or both that and the new 
nsMacWidget.rsrc file to change the cursor design also. (obv. the .rsrc file is a 
completely new .rsrc file, not a patch, ignore what I said above. sleepy!)

Its *amazing* how much faster Mozilla feels with this patch. Its an illusion of 
course, but the fact one feels one can point at the UI and interact is a huge 
psychological boost - works for me at least :)

Comment 45

[Peter "jag" Annema]

"=149" ?? Wouldn't it be nice to turn this into a kSomethingCursor or
NS_SOMETHING_CURSOR?

Comment 46

[Andrew Thompson]

Hmmm, well, only if you want to fix the other 20 resource numbers used in the 
file at the same time.
These are the numbers of the resource of to load from the resource fork of the 
widget.shlb (dll) file... they're not really used anywhere except on this one 
line where we fetch the cursor ... fundamentally its a resource *number* and I 
think using a constant only makes it harder to read.

Still, if people really feel I should I will. 

Comment 47

[Peter "jag" Annema]

Oh, no.... If resource numbers are standard practice in this case, ignore me :-)

I guess to me |kPurdyMacSpinningCursor| makes more sense than |149|, regardless
of how often I'd use |kPurdyMacSpinningCursor|. But like I said, ignore me :-)

Comment 48

[Patrick C. Beard]

r=beard, but I'd like to run with it a bit before I decide if I like it.

Comment 49

[Andrew Thompson]

Thanks Patrick. Try attachment 26118 [details] [diff] [review] for the C++ change, and then, if you want to 
see the arrow+ball cursor rather than the arrow+watch cursor that's already in 
Mozilla, get attachment 26119 [details] (its MacBinary encoded). Replace widget/src/mac/
nsMacWidget.rsrc and simply rebuild widget.mcp.

Comment 50

[Marcia Knous [:marcia]]

nominating for dogfood (from sdagley's list of bugs that are good candidates for 
our next release) 

Comment 51

[Andrew Thompson]

Patrick? You been running with this? Happy?

Comment 52

[Mike Pinkerton (not reading bugmail)]

man the current behavior is annoying. let's get this landed!

Comment 53

[Patrick C. Beard]

I am building with this patch right now.

Comment 54

[Mike Pinkerton (not reading bugmail)]

so in which bug should we debate the usage of any cursor changes in our UI to 
indicate "you can click on something"...which is what the pointer denotes?

we already have many other indicators of status, why muck with the cursor to tell 
them something they already know, that they can click?

Comment 55

[Andrew Thompson]

I just re-read the entire bug. It seems every possible avenue has been discussed, 
including 

1/ having one pointer for chrome and another for content
2/ changing the current spinning cursor to be more descriptive (arrow+ball)
3/ leaving spinning as it is and adding another kind of cursor that is 
descriptive and using that in the networking code instead of spinning
4/ pink and others have also suggested simply not changing the cursor *at all* 
while Moz is busy on the network.

I've been running with the patch that does 2/ for a couple of weeks now and I 
find it satisfactory.

For the short term I'd suggest
	* check this is
	* leave bug open and continue to debate or, if the other "problems" are 	
		seperable, open new bugs

Comment 56

[Andrew Thompson]

ping - Patrick... any conclusions?

Comment 57

[Patrick C. Beard]

I'm much happier with this cursor than the annoying beach ball. Let's check this 
in. r=beard

Comment 58

[Pierre Saslawsky]

I don't like this change but I don't have the time to organize a poll "who likes 
it? / who doesn't?".  In my opinion we should stick to the cursors provided by 
the OS when we can.  Reassigned to Pink to check if the kThemeSpinningCursor 
under OS-X deserves to keep the code as it is.

Comment 59

[Andrew Thompson]

I'm confused.

Pierre, you prefer a cursor where its impossible to work out where the hotspot 
you can click with is because its circular? A cursor which is traditionally used 
to indicate to the user that he or she can't click at all, when in fact its 
entirely possible interact with the chrome while this cursor is up?

I'd rather take *anything* than the current cursor. Just because its provided by 
the OS doesn't mean we're using it in the right context, which makes it the wrong 
cursor for the job.

I'm not emotionally attached to this particular cursor. I just want something 
which doesn't mean "you can't click now" to come up when I can in fact click.

If I recall correctly the cursor is the same on Mac OS X.

Comment 60

[Andrew Thompson]

> I just want something 
> which doesn't mean "you can't click now" to come up when I can in fact click.

Ugh. Sleepy. In English that sentence would read:

I think its important that Mozilla doesn't use a cursor which explicitly means 
"you can't click now" when the user actually can click if he or she wants to.

Comment 61

[Patrick C. Beard]

I love the new cursor. I've been running with it for a month or so, and I *HATE* 
the beach ball, which is utterly useless for this purpose.

Comment 62

[Pierre Saslawsky]

A solution would be to check it in and see how people like it.  If they are 
confused, it will still be time to change it back to a beach ball or something 
else before 1.0.

Comment 63

[Mike Pinkerton (not reading bugmail)]

i'll apply this patch and land it as soon as i get an sr. ooohhhh simon?? ;)

i assume i just need the final two patches?

Comment 64

[Simon Fraser [no longer active]]

sr=sfraser. Extra bonus points if you make a pointer/beachball that spins (like 
MacPerl).

Comment 65

[Andrew Thompson]

Mike,

There are acutally 2 options here. Mozilla already has an arrow+watch cursor in
nsMacWidget.rsrc, its just never used.

So if you apply the last 2 "patches" you'll get Matthew's Arrow+Ball, if you
apply only the second last patch (to nsWindow.cpp) you'll get the Arrow+Watch.

Naturally, the "patch" to the rsrc file is infact a complete replacement for it.
I just checked and you checked in a change to this file on April 4th so, in
fact, I'll have to respin if you want to go with the Arrow+Ball. Let me know...

Either works OK for me.

Simon: spinning the ball is something I'm thinking about. Probably needs to
interact with the throbber code or something like that. If I was going to fix
that, I'd also suggest getting rid of the VBL task that shows the watch on Mac
OS X (as the operating system does that for us) but that's a Whole Other Bug (tm)

Comment 66

[Mike Pinkerton (not reading bugmail)]

lp:

- don't worry, i did the right thing with the resource. i only copied out the 
changed cursor

- the code for the watch is already out of OSX, it's all wrapped in 
!TARGET_CARBON, since you can't have a VBL task on osx.

Comment 67

[Mike Pinkerton (not reading bugmail)]

landed (w/out the spinning beach ball, sorry smfr) ;)

Comment 68

[Mike Pinkerton (not reading bugmail)]

fixed

Comment 69

[Matthew T (active 1999-2002)]

Verified fixed, build 2001043008, Mac OS 9.1.

Filed the following bugs which resulted from this fix:
*   bug 78361, `"spinning" cursor during loading should not be overridden by
    html.css'
*   bug 78362, `"spinning" cursor on Mac should have a 1px white outline'
*   bug 78363, `Beachball in Mac "spinning" cursor should actually spin'.

Comment 70

[Terence Tan]

I know this is way, way too late, but I may as well throw it in:

I think it used to be Excel for Mac which had a 'spinning' cursor simply as a
white arrow, as opposed to a black one. During this time it was doing
calculations but you could still interact. Personally I'd prefer the white arrow
but I guess this bug is closed and finished with already :-)