67761 - Throbber should have normal cursor, not pointing hand cursor

Status: RESOLVED FIXED

(SeaMonkey :: UI Design, defect)

Description

[Matthew T (active 1999-2002)]

Build: 2001020513, Mac OS 9.0

To reproduce:
*   Mouse over the Home button, which (when clicked) takes you to an URL. Note
    the cursor used.
*   Mouse over a bookmark in the Personal Toolbar, which (when clicked) takes you
    to an URL. Note the cursor used.
*   Mouse over the throbber, which (when clicked) takes you to an URL. Note the
    cursor used.

What happens:
*   One of these things is not like the others, one of these things is not quite
    the same ...

What should happen:
*   The throbber button should use the normal cursor.

Comment 1

[Jesse Ruderman]

Is this Mac-only?  On Windows, personal toolbar buttons use the hand cursor (as 
does the throbber).

Comment 2

[Matthew T (active 1999-2002)]

If Personal Toolbar items use the hand cursor on Windows, that should be filed as 
a separate bug. None of the following should use the pointing hand cursor:
*   the Back button
*   the Forward button
*   the Home button
*   the throbber
*   items in the main menus which take you to an URL (e.g. Release Notes, items
    in the Bookmarks menu)
*   items in the Bookmarks menu in the Personal Toolbar
*   other items in the Personal Toolbar.

The pointing hand cursor should only ever be used for content, not chrome.

Comment 3

[Boris Zbarsky [:bzbarsky]]

Attachment: Patch to fix this in modern and classic

Comment 4

[Boris Zbarsky [:bzbarsky]]

I've filed bug 72176 on the personal toolbar issue.

Hewitt, could you review the patch?

Comment 5

[Håkan Waara]

r=hwaara

Comment 6

[Blake Ross]

hewitt, can you sr bz's patch please?

Matthew, you're probably right about the pointer cursor not being used in 
chrome, but I still cringe at the thought of an arrow cursor over a `button' 
with blue, underlined text.  Also, I thought the idea was that personal toolbar 
`buttons' would be as much like links as possible.  Has that changed?

Comment 7

[Matthew T (active 1999-2002)]

If Personal Toolbar button text is blue and underlined, that is also a bug. 
What if your system color settings are for blue chrome? That's unlikely, but 
not impossible. In that case, bookmarks that were hard-coded to be blue would 
disappear.

Comment 8

[Boris Zbarsky [:bzbarsky]]

blake, mpt, the personal toolbar discussion would be much more appropriate in
bug 72176.  mpt, the "blue and underlined" thing is defined by the theme itself
(as is the cursor).  In Modern it does not happen, in Classic it does.

Comment 9

[ratman]

i would suggest this as resolved wontfix simply because ns4.x behaviour is to
have a hand cursor over the throbber, and there's no good reason to switch.

of course, ns4.x also uses a normal cursor over personal toolbar elements and
bookmarks, so....

Comment 10

[Jesse Ruderman]

This isn't 4xp on Windows (4.77 on Windows uses a hand cursor for the 
throbber).  Is it 4xp on Mac?

Comment 11

[Boris Zbarsky [:bzbarsky]]

This is 4xp on Mac and Linux, I think.... On Linux the throbber gets a 1px solid
black border and the cursor stays a pointer.

Comment 12

[Boris Zbarsky [:bzbarsky]]

reassigning to hewitt.... trying to focus on other things.

Comment 13

[Joe Hewitt (gone)]

Mass reassigning my theme bugs to Shuehan.

Comment 14

[Joe Hewitt (gone)]

Comment on attachment 27873 [details] [diff] [review]
Patch to fix this in modern and classic

You should actually just remove the cursor line, no need to say cursor: default
because it will inherit that from button anyways.

sr=hewitt if you do that

Comment 15

[Håkan Waara]

Reassign to bz -- just fix hewitt's nits and you're ready to check this in.

Comment 16

[Boris Zbarsky [:bzbarsky]]

I had totally forgotten about this bug... :)

Checked in (just removed the cursor rules).

Comment 17

[Stephen Anderson]

Not that anyone asked for my two cents, but I would have prefered that the hand
cursor remain as the cursor over the throbber.  The bookmarks have a highlight
bar over the selected entry, the main buttons change color on mouse-over, but
the throbber does nothing.  If the throbber had a mouse-over effect, okay.  But
without some visual change, I liked the cursor changing.  Again, just my $0.02.

Comment 18

[Ben Ruppel]

This makes zero sense.  Clicking on the throbber takes you to a different web
site, yet there is no feedback that it is not just another part of the chrome
that does nothing when you click on it.  And quite frankly, I have to say that
MPT sounds like he's on crack when he says that links, even though they happen
to be in the chrome, should not give normal link feedback.  Consistency over
whatever rule MPT will quote for this.

Comment 19

[Christopher Aillon (sabbatical, not receiving bugmail)]

I tend to agree with mpt and bz but in this case I have to disagree to this
checkin.  For the record, I almost filed a bug on the throbber not having the
pointer cusor anymore.

Anyway, I do agree that there should be consistency in the behaviour of the Home
button, the items in the PT, and the throbber.  However, on Linux at least, the
consistency was already there.  This checkin just *broke* consistency on Linux,
and possibly on Windows according to jruderman's comment #1. For me, this is now
completely counter-intuitive.

Were the throbber to at the very least show some sign of it being "clickable"
this would be a moot point, but being that the animation doesn't start or a
pointer cursor is not displayed, it is no longer obvious to the user that
clicking on it will do anything.  It is just a part of the chrome now, and
without the pointer, it has become almost stripped from the UI from the user's
point of view.  You get the same responsiveness (or lack thereof) from the UI as
if we replaced the Mozilla logo with a 16x16 transparent GIF (or whatever size
the throbber logo is).  You have no way of knowing that the area is clickable at
all.

There needs to be some acknowledgement to the user that he/she is able to
perform an action by clicking the mouse over the throbber in order for it to be
useful.  Because of this checkin, there no longer is any.  Where is the rule
that chrome cannot have pointer cursors? If macs do not display a pointer cursor
for the 'Home' button or on the 'Personal Toolbar' items, yet the other two
platforms do, should it not be a bug on the Mac only for it's inconsistencies
rather than on the platforms that were consistent?  Is there any good reason why
we should NOT display the pointer cursor for Home, PT, and throbber?

The pointer cursor is traditionally used for hovering over links, and personally
I see no reason not to continue to use it as such.  There is a difference
between a button which serves a specific purpose (Back/Forward) and an image or
toolbar item which is a direct link to a page.  Let's not make up reasons to
combine them.  It is like <input> and <select> vs. <a> - both will likely change
the content window's location, yet I expect a pointer on an <a> and a default
arrow on an <input> or <select>.  Compare the back/forward buttons and their
drop downs to <input> and <select> and the throbber to <a><img/></a>.

I propose backing this out and looking for a solution on the Mac side only
(which this bug happens to be filed as a mac specific bug). Please don't break
the UI consistency on any platforms just to fix it on one.

Comment 20

[Ben Ruppel]

I'd like to say that I apologize for being harsh of mpt on my last post, but
look at the average mpt statement: 

"X behavior which seems intuitive and logical to a number of people is obviously
wrong and the worst ui behavior ever conceived.  If there are other cases which
make X behavior seem appropriate, then those cases are wrong as well.  (And no,
I'm not gonna tell you why.)"

As for the problems with link colors clashing with chrome: isn't that
controllable in a css file for the particular chrome?  If I had a blue toolbar,
I could make link mouseovers orange, no?

Comment 21

[Claudius Gayle]

there is a lot of merit to the idea the the throbber is a button and should
behave that way (no pointer cursor) I get it, really I do. That leaves two
problems though: 1. It will now take a crusade to get this behavior 'fixed'
consistently on all the platforms and 2. The throbber isn't acting like other
buttons. All the other buttons either have a tet label OR show mouseover action.
The throbber does neither - and that's exactly why it used to have the pointing
hand ('clickme') cursor.

I'm reopening the bug because I sho' nuff am not going to verify the fix.

Comment 22

[Claudius Gayle]

reassinging to hewitt because he sr'd it and I believe that is the level where
we have disagreement as to the proper fix for the 'big picture' (overall
betterment of the app).

hewitt, if after reading the discussion here, you still feel this fix is the
best sol'n or it still needs to go forward as part of a larger sol'n then fine,
resolve it fixed and I will verify.

Comment 23

[Joe Hewitt (gone)]

-> shuehan

Comment 24

[Boris Zbarsky [:bzbarsky]]

OK.  People have a valid point -- it would be nice if the throbber gave some
feedback that it's clickable (as the back/forward buttons do).

The NS4 throbber gets an outset border onmouseover.  Would that be a decent
solution?

Comment 25

[Stephen Anderson]

Can we please forget for just a moment what we have done in the past and work on
making the user interface consistant?  I'm on W2k modern theme and this is what
I see on mouse-over:

Bookmarks:  Color reversal like every other menu item
Bookmarks folder and Document folder on personal and site nav toolbar: Outset border
Links on personal toolbar: Underline and hand-pointer
Home button on personal toolbar: Underline and hand-pointer
Site nav toolbar links: Underline, hand-pointer, and icon color change
Forward Back Buttons: Color change
Go button: Nothing
Search button: Nothing
Throbber: (Now) Nothing

We have 9 different items here with 6 different behaviors.  Giving the throbber
an outset border would put it on par with every other drop-down menu item.  I
don't think that is a good idea from a consistancy point of view.

Right now the Go, Search, and Throbbers all give ZERO feedback that they are
clickable, unless you count the optional tool-tip.  Go, Search, and Throbber
will all take you some place.  If you want consitancy (and I know I do) I think
the consitant option is:

1) Menu Items (Bookmarks): Color Reversal
2) Drop Down Menu Items: 3D Outset Border
3) Text Links: Underline and hand-pointer
4) Graphics accompanying text links: Graphic color change OR No color change
5) Buttons: Graphic color change

To make the UI consitant with those 5, the following changes would be required:
1) No changes for this proposal
2) No changes for this proposal
3) No changes for this proposal
4) If color change, then Home, bookmark icon on personal toolbar need color
change.  If No color change then remove color change from site nav link
graphics.  The latter is easier, but I prefer the former.
5) Go, Search, and Throbber receive mouse-over color change consistant with all
other buttons.

Ehhh... just my $0.02.  Course, in the short-term I'd be happy if you reverted
the change that is this bug.

Comment 26

[Matthew T (active 1999-2002)]

> Consistency over whatever rule MPT will quote for this.

The rule is ... consistency. The hand cursor is used in content, because content
is (mostly) at the whim of the author, and has highly unreliable appearance. You
need extra help to identify what is a link and what is not, and the cursor
provides that help.

There is, however, no excuse for using the hand cursor in chrome. It should be
blatantly obvious what a control does without cursor changes, and the visual
instability caused by adding a cursor to the mix (except for the
well-established I-beam cursor for text fields) outweighs any benefit it might
provide. Think how odd it would look if, for example, the `Get New Themes' menu
item (which takes you to a URI) had a hand cursor, but all the other items in
that submenu had a normal cursor. Or if the `Open' button in the `Open Web [sic]
Location' dialog (which takes you to a URI) had a hand cursor, but the `Cancel'
button right next to it had a normal cursor. On crack, indeed.

Now, it seems the root source of complaint here is that the throbber doesn't
look clickable. It's not a throbber's primary function to look clickable, of
course; its primary function is to show loading feedback. It doesn't look
clickable in Netscape 3.x for Windows, Netscape 3.x for Unix, MSIE 3.0 for Mac
OS, or any version of MSIE for Windows from 4.0 upwards, yet I don't remember
anyone complaining about it. If, however, you would like the throbber to have a
border like other toolbar buttons, go ahead and file a bug for it -- it already
has such a border (all the time, not just on mouseover) in Mac Classic.

> As for the problems with link colors clashing with chrome: isn't that
> controllable in a css file for the particular chrome?

No. The background color of the Classic chrome is determined (on Windows, and in
theory on Mac OS too) by your settings in the relevant OS control panel. There
is no setting in that control panel for `chrome links', however; their color is
hard-coded into the Classic theme. So if you're a night person and you set your
Windows settings to white text on blue chrome, you're screwed.

Comment 27

[Stephen Anderson]

>The rule is ... consistency. The hand cursor is used in content, because content
>is (mostly) at the whim of the author, and has highly unreliable appearance. You
>need extra help to identify what is a link and what is not, and the cursor
>provides that help.

The UI is at the whim of a different kind of author and has a highly unreliable
appearance!  That's why we are complaining.  We need extra help to identify what
is clickable and what is not.

>There is, however, no excuse for using the hand cursor in chrome.

So you are going to crusade for removing the hand cursor from being used in the
personal and site nave toolbars too?

>If, however, you would like the throbber to have a
>border like other toolbar buttons, go ahead and file a bug for it

Maybe you'd like to file that bug, and bugs for the Go and Search buttons as
well.  But please revert this change until those bugs are finished.  You have a
made a change in the name of consistancy (which is questionable at best
considering all the other incosistancy in the UI) at the expense of usability.

PS: For consistancy, the dropdown arrows on the forward, back, print buttons,
and url bar should receive a mouse-over outset to look like every other
drop-down menu item.

Comment 28

[Ben Ruppel]

>There is, however, no excuse for using the hand cursor in chrome. It should be
>blatantly obvious what a control does without cursor changes
But it isn't (yet?).

>and the visual instability caused by adding a cursor to the mix (except for the
>well-established I-beam cursor for text fields) 
A hand cursor to represent an object which will take you to another page is
probably THE most well established part of browser UI you can think of.

>There is, however, no excuse for using the hand cursor in chrome. 
OH NO!  We've been bad boys!  Please forgive us!

>Think how odd it would look if, for example, the `Get New Themes' menu
>item (which takes you to a URI) had a hand cursor, but all the other items in
>that submenu had a normal cursor. Or if the `Open' button in the `Open Web [sic]
>Location' dialog (which takes you to a URI) had a hand cursor, but the `Cancel'
>button right next to it had a normal cursor. On crack, indeed.
Yes, if you think that is a valid comparison.  Your argument, however, is
comparing apples to oranges.  Menuitems are nestled withing menus, don't have
icons or any other graphics, and are totally dissociated from the browser front end.

>Now, it seems the root source of complaint here is that the throbber doesn't
>look clickable. It's not a throbber's primary function to look clickable, of
>course; its primary function is to show loading feedback. 
Then don't make it a link.  Note how images in web pages get a hand cursor over
them, and that's how you know they're clickable.  But I guess the chrome should
have TOTALLY DIFFERENT RULES from everything else, because changing a cursor is
far too jarring and might cause epilepsy.  

>It doesn't look clickable in Netscape 3.x for Windows, Netscape 3.x for Unix,
>MSIE 3.0 for Mac OS, or any version of MSIE for Windows from 4.0 upwards, yet I
>don't remember anyone complaining about it. 
Yes, that was a bad mistake.  I actualy remmeber first discovering that the
throbber was clickable, and remarking of how non-obvious (and stupid) it was.

>If, however, you would like the throbber to have a border like other toolbar
>buttons, go ahead and file a bug for it -- it already has such a border (all
the >time, not just on mouseover) in Mac Classic.
Oh yeah, that's a great idea.  Why don't we put borders around our forward and
back buttons too?  Borders belong around menus and menu-like items.

>No. The background color of the Classic chrome is determined (on Windows, and in
>theory on Mac OS too) by your settings in the relevant OS control panel. There
>is no setting in that control panel for `chrome links', however; their color is
>hard-coded into the Classic theme. So if you're a night person and you set your
>Windows settings to white text on blue chrome, you're screwed.
Allow me to pull out my violin.

Comment 29

[Matthew T (active 1999-2002)]

> The UI is at the whim of a different kind of author and has a highly
> unreliable appearance!

So file bugs. The UI shouldn't look unreliable, and giving it funny cursors 
isn't going to make it look reliable.

> So you are going to crusade for removing the hand cursor from being used in
> the personal and site nave toolbars too?

For the Personal Toolbar, absolutely -- it didn't have a hand cursor in 4.x, 
and it doesn't need one now. For the Links Bar, definitely not, because it 
should be presented as part of the page rather than part of the chrome (see 
various dependencies of bug 103053).

> > If, however, you would like the throbber to have a border like other
> > toolbar buttons, go ahead and file a bug for it
>
> Maybe you'd like to file that bug, and bugs for the Go and Search buttons as
> well.

They would be invalid, because all those buttons already do have borders. If 
any of them don't in Windows Classic, file bugs.

> Menuitems are nestled withing menus, don't have icons or any other graphics,
> and are totally dissociated from the browser front end.

In the case of the Bookmarks menu in the Personal Toolbar, that is untrue in 
every respect. Nevertheless, it still uses a normal cursor.

> I guess the chrome should have TOTALLY DIFFERENT RULES from everything else

No, it's links in Web pages which need different rules from everything else, 
for the reasons I described in my previous comment.

> I actualy remmeber first discovering that the throbber was clickable, and
> remarking of how non-obvious (and stupid) it was.

Exactly. The throbber doesn't need to be a link, and the fact that it does
something when clicked is more an Easter egg than a useful feature.

> Why don't we put borders around our forward and back buttons too?

Absolutely -- that's bug 50693.

> Borders belong around menus and menu-like items.

Your violin-playing could be improved, but your revisionism is very impressive.
<http://iarchitect.com/visual.htm#VISUAL36>
<http://iarchitect.com/visual.htm#VISUAL38>
<http://hnehosting.com/mirrors/Origin_of_a_Browser/screenshotsright4.html>

Comment 30

[shliang]

The throbber has the visual style of a button and not a link, so it should not 
have a hand cursor. And as mpt said, the fact that it does something when 
clicked is more an Easter egg than a useful feature.
 

Comment 31

[Christopher Aillon (sabbatical, not receiving bugmail)]

Shliang, so if you're WONTFIXing this bug which *wants* a normal cursor, then
the current behaviour of a normal cursor is wrong.  Let's put back the hand
cursor. ;)

Reopening to mark this with the correct resolution (as fixed).

I have filed bug 120698 for giving user feedback that the throbber is clickable.
 Let's move discussion over there.

Comment 32

[Christopher Aillon (sabbatical, not receiving bugmail)]

.. and marking fixed.