481359 - Mouse shouldn't show spinner while pages are transferring

Status: VERIFIED FIXED

(Core :: General, defect)

Description

[Robert Sayre]

This has never looked good. It tends to flicker too much and look generally low rent.

This is a mouse pointer with a circle off to the side.

Comment 1

[Markus Stange [:mstange]]

Attachment: fix v1

Comment 2

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 365464 [details] [diff] [review]
fix v1

Seems like this should be an app-level preference, not Gecko policy.

Comment 3

[Robert Sayre]

(In reply to comment #2)
> (From update of attachment 365464 [details] [diff] [review])
> Seems like this should be an app-level preference, not Gecko policy.

build time? we have to stop preffing out every behavior change...

Comment 4

[Mike Shaver (:shaver emeritus)]

What application will want it, and not be able to do it at the app level with a cursor change?  I think this is a saner default, and would be pretty surprised if an app would prefer the flickery current behaviour.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Comment 3 is not really compatible with the whole "multiple apps use same xulrunner" thing.  Which is why we have prefs for behavior that said apps might want to differ on...

I'm not sure what "cursor change" comment 4 means...

Comment 6

[Boris Zbarsky [:bzbarsky]]

In particular, there is no way I know of to show the "busy" cursor on things which otherwise would be default/auto while showing the hand cursor on links, say, without this code...

Comment 7

[Mike Shaver (:shaver emeritus)]

I think we should see if there are actually any applications that want the current flickery stuff before we add the complexity of a pref.  We shouldn't pref everything just because someone might want it, since everyone has to bear the cost of the code.

Comment 8

[Boris Zbarsky [:bzbarsky]]

I can live with that, though I'm not sure why people keep saying it's flickery.  Do you mean that it changes as you move the mouse around or something else?

Also, note that the code is there to start with because a particular app did want the behavior in the past....

Comment 9

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 365464 [details] [diff] [review]
fix v1

This looks ok code-wise, for sure.

I'm semi-convinced we can just rip it out, since no other browser seems to do this.

Comment 10

[Robert Sayre]

(In reply to comment #8)
> I can live with that, though I'm not sure why people keep saying it's flickery.
>  Do you mean that it changes as you move the mouse around or something else?

If a site loads quickly, it pops in briefly. On more complex sites, it flickers as ad networks and things load in. http://www.yahoo.com is an example.

It's really only working well when you try to visit a site that's responding slowly, like submitting a bugzilla form. But even then, it's redundant, because we have other throbbers.

Comment 11

[Boris Zbarsky [:bzbarsky]]

Ah, ok.  Fair point.

Comment 12

[Nochum Sossonko [:Natch]]

IMHO the (semi)busy cursor is a good thing, having a throbber on the far top-right corner of the app doesn't tell the user "be patient, we're getting/laying out your page for you!", in fact most users probably don't really pay much attention to it. OTOH the busy cursor does. The "flickering" is just a sign that Firefox is too fast :) . This could be tweaked though, so that it doesn't show in some cases (i.e. in the case of image loading). Just My .02

Comment 13

[Robert Sayre]

(In reply to comment #12)
> IMHO the (semi)busy cursor is a good thing, having a throbber on the far
> top-right corner of the app doesn't tell the user "be patient, we're
> getting/laying out your page for you!"

That's just the problem. It often happens when there is no need to be patient.

Comment 14

[Robert Sayre]

and, actually, the spinner does move the mouse pointer one pixel left, and one pixel up. gross!

Comment 15

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 365464 [details] [diff] [review]
fix v1

uir=beltzner

Pretty sure faaborg will agree; this isn't platform standard, and the feedback (as Rob says) is a duplication of our existing "loading" indicator, distracting, and often misleading.

The only time I've found this useful is when we're doing an XHR in a frame and I need to see if that's loading, but really, we should just be doing better there about figuring out how to relay progress (or the web author should)

Comment 16

[Alex Faaborg [:faaborg] (Firefox UX)]

Yep, I totally agree, and am also a little embarrassed that I never caught this myself when looking for polish problems.

Comment 17

[Boris Zbarsky [:bzbarsky]]

Yeah, XHR in a frame should really not be triggering this.  If it was, that's a good reason to just nix it.

Comment 18

[Markus Stange [:mstange]]

pushed: http://hg.mozilla.org/mozilla-central/rev/c5d3a01ab59c

Comment 19

[Robert Sayre]

Hmm, I'm still getting a spinner clicking on the Facebook navigation. How would that happen?

Comment 20

[Markus Stange [:mstange]]

I'll see if I have missed something.

Comment 21

[Markus Stange [:mstange]]

Facebook does it. I found this in their source code:

element.style.cursor = document.body.style.cursor = 'progress';

Comment 22

[Shawn Wilsher :sdwilsh]

Comment on attachment 365464 [details] [diff] [review]
fix v1

We'd like to see this polish bug landed on branch, so requesting approval.

Comment 23

[Paul-Kenji Cahier]

Just wanted to point out a bug has been open because of this bugfix:
https://bugzilla.mozilla.org/show_bug.cgi?id=482985

That spinner was actually useful to many users.
It might not have been perfect but it served a role. Now there's nothing.

Comment 24

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 365464 [details] [diff] [review]
fix v1

a191=beltzner

Comment 26

[Dão Gottwald [:dao]]

http://hg.mozilla.org/releases/mozilla-1.9.1/rev/4ad59d117236

Comment 28

[Aakash Desai [:aakashd]]

verified FIXED using https://litmus.mozilla.org/run_tests.cgi and spanning through queries as well as test suites on builds: 
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090430 Minefield/3.6a1pre ID:20090430031133

and

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b5pre) Gecko/20090430 Shiretoko/3.5b5pre ID:20090430031222

Thanks guys!

Comment 29

[[e-mail]]

(In reply to comment #10)
> we have other throbbers.

I've obviously got used to one particular case - when links open a new window, the spinner is the only indication you have that your click actually worked...

Comment 30

[Alex Faaborg [:faaborg] (Firefox UX)]

This bug's priority relative to the set of other polish bugs is:
P1 - Polish issue that appears in the main window, or is something that the user may encounter several times a day.

page loads are obviously pretty common, making this bug clearly something that the user was encountering several times a day.

Comment 31

[bslwannabe]

I'm unclear as to how this bug was "verified fixed". Did the code to have a load cursor get expunge, did a pref get added so users can have it back? I suspect that the former is the case bt the comments here suggest the later. Which is it? And if a pref was added what's it name?

Comment 32

[Boris Zbarsky [:bzbarsky]]

> Did the code to have a load cursor get expunge

Yes.  You can read the patch, if desired; it's attached to this bug!

Comment 33

[Paul-Kenji Cahier]

You might want to just go talk onto 482985 which is about fixing the aftermath of this "bug".