Mouse cursor does not change upon page load/refresh

Also note that the throbber is not longer default so users now have to figure out which tab has focus and then look at that tabs favicon. Granted it is only a very small ammount of time to do that but who knows for people with disabilities trying to differentiate between an active and non active tab.

Note a core issue. The decision in bug 481359 was that if an app wants the behavior it can set the cursor override on the window. Of course an extension can do the same.

I have no idea why anyone would want to differentiate between active and inactive tabs, though....

Usually to find out which pages have loaded and are ready to be looked at.

(In reply to comment #2)
> Note a core issue. The decision in bug 481359 was that if an app wants the
> behavior it can set the cursor override on the window.

Bug 481359 comment 6 doesn't seem to support that.

(In reply to comment #4)
> (In reply to comment #2)
> > Note a core issue. The decision in bug 481359 was that if an app wants the
> > behavior it can set the cursor override on the window.
>
> Bug 481359 comment 6 doesn't seem to support that.

Yet bug 481359 comment 21 indicates that there is a JS mechanism to activate this.

Changing the cursor is not the issue. I believe actually knowing when to do it is more of the issue here.

Yeah, there's knowing when to do it, and also doing it reliably while maintaining the correct hover behavior for links etc. I'm not sure that that works correctly.

(In reply to comment #5)
> Yet bug 481359 comment 21 indicates that there is a JS mechanism to activate
> this.
That mechanism alters the page. There isn't one that doesn't alter the page, although I guess one could be added to nsIDOMWindowUtils.

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

Chrome has the semi-loading cursor as well. This also seems to be the os standard on Windows, when a new folder is loaded in Windows explorer or a new file opened in most applications, the cursor turns to the loading cursor.

Seems like this is pretty much expected by most users. Just because it wasn't 100% doesn't mean it should be removed, IMHO, it only needs to be made more accurate.

How do people feel about a removing the loading cursor only on Mac OS X?

See also bug 362623 comment 5, which suggests changing cursor: progress there, too.

I personally think that since things were originally reported by OS X users, it should only be removed there.

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

In fullscreen mode, there is now no possibility to monitor the page load progress. There is an urgent need, to have hourglass as an indicator.

(In reply to comment #14)
> In fullscreen mode, there is now no possibility to monitor the page load
> progress. There is an urgent need, to have hourglass as an indicator.

Great point Maksym!

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

Getting this reverted on non-OSX-systems would be nice. You always think nothing happens if you click a link and the cursor doesn't change.

Is there any easy way (i.e. without recompiling) to re-enable the loading cursor manually?

Not as far as this thread and some others went. I personally have been forced to compile my own builds with the patch that causes this issue removed.

Some have hinted that it might be possible to have an extension to do it, but so far it does not seem to be that easy(mostly because it's hard to known when things are loading)

That's why I originally created this bug report, because I could not find any simple way to solve the issue.

I recompiled with this [http://hg.mozilla.org/releases/mozilla-1.9.1/rev/4ad59d117236] patch being reverted, but there's still no loading cursor. Is there anything else which needs to be changed?

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

Are there any plans to fix this on non-OSX systems in 3.5.1? Or make it at least configurable via about:config?

This is _not_ a feature for users who are stuck with dial-up. I do not have access to other types of connection where I live, and to me this is a deal-breaker. Firefox just becomes needlessly hard to use, and that is very demotivating, considering there is no reason to omit an about:config tweak to re-enable the cursor.

I sincerely do not understand why this patch was silently slipped in inbetween betas 3 and 4, without consideration for the implications.

It was a rushed decision, and quite frankly, a mistake.

I have to agree that it was a mistake to remove it. And there should at least be a simple option to enable it again.

When I'm navigating quickly through a site and suddenly a link is clicked that is not immediate I used to be able to get instant feedback that it was clicked but now I have to look up at the tab bar (which I usually have ~20 tabs open in) and search for the active tab to know if I actually clicked it. So it has slowed my browsing experience.

Also when you are viewing pages in fullscreen mode or without tab/toolbars like in some popup windows there is absolutely no indication that a slower page is loading or not.

The loading cursor is part of my daily browsing experience... or at least was until now and I wish for it back.

I want to confirm that I'm missing the "busy mouse" animation very much, especially on my netbooks (ubuntu 9.04) with VerticalTabs: No throbber, throbber on tab is very small.

Especially with slow internet connection you have no idea that the link has actually been clicked.

On small screens people tend to use fullscreen mode or turn off the status bar. If you browse the web you always have the mouse cursor in focus, but now there's no more indication what's happening.

Bad idea to remove this!

Created an attachment (id=388666)
only remove on OS X

We've got several options:
 1. Wontfix this bug,
 2. put the code back in place, #ifndef'd for OS X,
 3. Add a pref
   3.1 defaulting to off on all platforms, or
   3.2 defaulting to off only on OS X.

I'm not the right person to make the decision.
This patch implements 2.

I believe the correct option is:
4. Implement it as part of Browser code.

The main problem with original throbber was that it was a Core code, and this is where it doesn't belong. Bringing that implementation back is not what anyone wants. See comment #2.

OK, but then somebody else will have to do that. I don't know how and I don't want to do it.

(In reply to comment #27)
> The main problem with original throbber was that it was a Core code, and this
> is where it doesn't belong. Bringing that implementation back is not what
> anyone wants. See comment #2.

The assumption in comment #2 (and bug 481359) was that an app can (reliably) set the cursor override on the window, which is not currently possible - at least not without changing core interfaces - if I understand comment #7 and #8 correctly.

> Bringing that implementation back is not what anyone wants.

I don't think that is true, but that's a matter of opinion.

> We've got several options:
> 1. Wontfix this bug,
> 2. put the code back in place, #ifndef'd for OS X,
> 3. Add a pref
> 3.1 defaulting to off on all platforms, or
> 3.2 defaulting to off only on OS X.
I think either 2 or 3.2 are the best solutions.
1 or 3.1 wouldn't be consistent with other windows programs - almost all programs (including explorer and IE) display a busy-cursor when loading new data or when you do something which is not finished immediately (e.g. clicking a link loading new content).

(In reply to comment #26)
> 3. Add a pref
> 3.1 defaulting to off on all platforms, or

Of your options, this is the only one that solves the issue that there's no feedback at all in popups or in full-screen mode. There's nothing platform-specific about that.

Another option would be to backout bug 481359.

(In reply to comment #27)
> I believe the correct option is:
> 4. Implement it as part of Browser code.

There's no concrete proposal how this could actually be implemented, as far as I can see.

> The main problem with original throbber was that it was a Core code,

This seems to be a pure invention on your side.

(In reply to comment #31)
> (In reply to comment #26)
> > 3. Add a pref
> > 3.1 defaulting to off on all platforms, or
>
> Of your options, this is the only one that solves the issue that there's no
> feedback at all in popups or in full-screen mode.

Err, I misread your proposed solution. Only if the pref would default to 'on' would it solve the problem, as the use cases in question aren't uncommon in such a way that only advanced users would want to opt in to the old behavior.

(In reply to comment #11)
> How do people feel about a removing the loading cursor only on Mac OS X?
>
> See also bug 362623 comment 5, which suggests changing cursor: progress there,
> too.

I dual boot my Mac into Windows / OS X and I miss this feature in both. Not seeing an immediate visual cue of when I've clicked on something and it showing that it's actually loading as intended is a little unnerving, as I've been an FF user since the early days and I've grown accustomed to it.

I don't know if the original loading animation is necessary. Maybe a quick animation that just lets you know that something started to load and then we'd have to rely on the various throbbers for any further feedback?

(In reply to comment #33)
> I don't know if the original loading animation is necessary. Maybe a quick
> animation that just lets you know that something started to load and then we'd
> have to rely on the various throbbers for any further feedback?

One major issue is the lack of any indicator in fullscreen mode, which is the sensible mode on any low-res device (mostly netbooks). The 'start' animation would be useful, but we still would have no idea if/when the page-loading is completed. This could also be a serious issue on Ajax-heavy sites.

Now part of what started it all, if I understand correctly, was the feeling that the original cursor animation seemed to go into a frenzy if a page loaded a large number of resources (.css, .js, .png, etc.). Would it be possible to bind the cursor to whatever controls the tab throbber? That one seems to merely start on page loading and stop on page loaded. We'd have a reliable and consistent indicator.

I can't really help on the Mac UI integration issue, not having Mac OS myself, but wouldn't a (crippling?) lack of UI be worse than a not-native UI?

(In reply to comment #31)
> Another option would be to backout bug 481359.

Since the popup/fullscreen feedback problem is really cross-platform, I think backing out bug 481359 is the only sensible solution here. Adding a pref defaulting to "show loading cursor" will only help users that know the pref exists (and do not use fullscreen mode, presumably), which feels like the wrong solution to the flicker issue on OS X.

Really not a core issue. If you need additional core APIs here, file bugs about them. But the app folks wanted to be freed from core forcing a cursor here, and they have that. Please don't move the bug to core again, ever.

And to be even more clear, if you want to set the cursor in app code you can do that already.

If you can't figure out _when_ to do that, that's more or less your problem; neither can the docshell code. App has strictly more information here than docshell does.

If the issue is that you want to set the cursor only in some states and not others, then it sounds like we need a new magic cursor value for that; that would be the "additional core api" I mention in comment 36.

If you want to just back out bug 481359 while you figure out the right way to fix this and then put that patch back in, I can probably buy that. But let's stop thrashing the core code here every time the Firefox UI wants changing.

And just to be very clear, I am strongly opposed to any platform ifdefs in this code if they can be avoided. If we have to have per-platform behavior in the core (which I'm not seeing any need for!) it'll be a pref.

It is, indeed. It relates back to the first days of the bug. It should be re-evaluated...

This is now very NOT comfortable to use after this cursor is missing.
Please fix that if possible.
We got such buggy version to Ubuntu 9.10 as well.

If WONTFIX is there because the developers can't then fine but to WONTFIX because they don't like it is unreasonbable and arrogant. I agree with other posters who say that the WONTFIX must be re-evaluated in the light of user requirements not programmer prejudice.

WTF nofix?! Everyone complains this totally sucks;

Also this is clear reason - this is NO visual feedback that page is loading.

Most annoying change in firefox I seen in years.

Please fix it

It is 1.9.1 wontfix. From what I understand, that means "wontfix in 3.5.x". At least the 3.7 compiled from trunk has the about:config setting...

(From update of attachment 401141)
Don't think we want to take this on the branch without bug 534538 addressed.

(From update of attachment 401212)
With ui.use_activity_cursor set true this regresses bug 487382

(From update of attachment 401212)
I don't suppose someone else exists who can do this ui-review more quickly?

Where are we on this one? Will it make it in time for 3.7? Or maybe under the Lorentz model...

What's the current state of this? Did the about:config option make it into the current release version?

It's not in 3.6, but it's in Minefield (3.7a1pre). So I guess 3.6 probably has been WONTFIX'd. We'll have to see what Lorentz brings or Firefox.next (4.0?) brings.

Or somebody could make an extension to bring this function back for those not using Minefield.

There are other Bug Reports that get marked as a "DUPE" to here so to avoid a separate posting I will mention my NEWer "Cursor Bug" here:

Up until yesterday I had updated Namoroka regularly (I have 'Nightly' 3.6.2pre, today's Update is awaiting a restart) and had noticed no Cursor problems.

I visited this page for the first time ever: http://en.ergoline.de/content/index.php/4/1424/2189/design_elements_-_the_ergoline_look.htm which leads to a '3-D QuickTime Player page' here: http://en.ergoline.de/content/popup/qtvr/soltron.php ). I've used the QT Player before but never been to that particular Webpage.

Now if I move my Cursor I get the "Regular Pointer" but when I let go of the mouse the Cursor changes to a "Target" (it looks similar to "(.)" except the circle closes and the dot is central, it seem's to be Quicktime's Cursor but Namoroka does not restore it's own over the "Webpage Area").

This only occurs while mousing over the 'Webpage Area' in Namoroka, when I leave that area either for the Tabs, Menus, or a different Application's Window then the Cursor is "Normal" (a Pointer, usually).

Rob

(In reply to comment #92)
> It's not in 3.6, but it's in Minefield (3.7a1pre). So I guess 3.6 probably has
> been WONTFIX'd. We'll have to see what Lorentz brings or Firefox.next (4.0?)
> brings.
>
> Or somebody could make an extension to bring this function back for those not
> using Minefield.

Are there any chances this is back ported to 3.6? Sugar [1] and it's Browse activity [2] are using this as an important user feedback when loading pages.

Even in new releases like Fedora 14 [3] we have 3.6. I already patched F11 for OLPC releases [4].

[1] http://sugarlabs.org/
[2] http://wiki.sugarlabs.org/go/File:Browse_0.86_palettes_improved.png
[3] https://bugzilla.redhat.com/show_bug.cgi?id=640581
[4] http://dev.laptop.org/ticket/10383

Isn't this a dupe of bug 481359?

(In reply to comment #95)
> Isn't this a dupe of bug 481359?

No...

(In reply to comment #96)
As so this isn't adding back what that removed? Sorry was just attempting to clarify.

This is a considerably bigger problem in Firefox 4 builds. With the throbber gone by default (I think?) and the status bar outright removed, the only remaining indication that a page is loading is the throbber in a tab's favicon. And the tab isn't in a consistent place, so you have to hunt for it first.

I've been on 4 full-time for a couple weeks now, and several times I've found myself confused as to whether Firefox is actually doing anything, even with FIOS.

This has been a serious usability problem for approaching two years. Showing the progress cursor after clicking a link is Windows UI 101. I've long since lost hope.

I'm pleased to see that setting ui._use_activity_cursor to true in about:config gives back the busy cursor. Why it's not set by default – nobody knows… (o;

I'm running trunk Minefield/Linux 64-bit, with ui._use_activity_cursor enabled, and although the pref works, the result is disappointing, because most cursors do not seem to have a "busy" version.

For example, after clicking on a link, the cursor does not to change to a busy cursor until after I move the cursor from the clicked link. That is, there does not seem to a be busy version of the link-hover cursor. The same goes for the caret cursor. This makes the pref a lot less useful than it could be.

Per, you're right. I am missing these busy cursor versions too, because it's sometimes confusing: has my click been accepted or not?

It's been two years, and I'm still HUGELY missing that option...I don't like clicking and not knowing immediately the click has been taken into account. To me it makes the browser look slower than Firefox 3.0...(when, I guess, it was removed for the opposite reason)

It's especially a problem in full screen mode, but not only. (the wait icon in the toolbar is much less visible)

I heard this was added back with a preference (ui.use_activity_cursor) but I tried and it doesn't work in the final Firefox 4.0 version! Big disappointment.

Is there any extension to bring back? Is it planned for a future Firefox version?

(In reply to comment #103)
> I heard this was added back with a preference (ui.use_activity_cursor) but I
> tried and it doesn't work in the final Firefox 4.0 version! Big
> disappointment.

Sounds like somebody isn't using a clean profile, cause the activity cursor preference in about:config works for me. Please go to SUMO to get help on your problem: http://support.mozilla.com/

In Chrome pointer becomes busy state when it is over the page content. Whem mouse moves over toolbar or tabs pointer becomes normal state and vice versa. I think his is right behaiviour and Firefox should do the same.

Vova, you should file a new Firefox enhancement request then. This bug is for the missing mouse activity cursor from Firefox 3.5 and 3.6.

In face, should this bug be closed as RESOLVED FIXED? The activity cursor is in Firefox 4 and Firefox 4 is out.

Really? This functionality is in version 4.0? I've not seen it there (4.0.1 running on Mac OS X (10.06.7)). If it is there then how do I activity it? All I see is a purile little counter-clockwise/clockwise activity indicator in the tab. The original request, which I think I posted, was for the cursor shape to change. I do *NOT* see that in 4.0.1.

The low-level functionality seems to be restored, but hasn't been enabled by default for Firefox. I don't think this issue is resolved until it's again enabled by default. This isn't esoteric behavior that only a few people want; this is basic user feedback, at least on Windows.

You can enable it via "ui.use_activity_cursor" in about:config. I don't know if there are still issues preventing it from being used by default; it seems to be working for me, for what it's worth.

Several of us wanted (want!) it on Mac OS X too. Setting ui.use_activity_cursor does indeed give a mouse-cursor indicator. It's so long since I last saw an activity cursor that I've forgotten exactly what it looked like but what I'm seeing now seems to be more appropriate. (I think then it was just a colour wheel; now it's a pointer with a small wheel.)

Filled https://bugzilla.mozilla.org/show_bug.cgi?id=659573

(In reply to comment #106)
> Vova, you should file a new Firefox enhancement request then. This bug is
> for the missing mouse activity cursor from Firefox 3.5 and 3.6.

I filed a new request for FF4 for this issue: https://bugzilla.mozilla.org/show_bug.cgi?id=659353

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

Comment on attachment 401212
adjust pref defaults

While feedback is really important, I (and the rest of the UX team) feel that changing the cursor based on network state is overly noisy and distracting, and makes the UI less zen. I'm fine with this being a hidden pref, but we want the default UI to be calm and sleek (and of course still provide great feedback in a consistent location).

It's not distracting for something to happen when you click a link; it's distracting for *nothing* to happen when you click a click.

Sitting around for a while after clicking just to realize that the browser missed the click is aggravating, not "zen". The tab icon isn't a consistent location (tabs move), it's far removed from the action needing feedback (the user's eyes are on the cursor; he shouldn't have to look somewhere else after every click), and in fullscreen there are no tabs to begin with.

The result is a UI that lacks feedback and feels unresponsive. This is akin to pages that remove link underlining despite the UI breakage it causes, because they think it looks "sleek".

Apparently, this has been fixed in 9.0. I get a busy cursor now when a page is loading. It's not the system's busy cursor (Linux/KDE), but that's OK with me. Thanks for fixing!

Nope. I am using 9.0.1 on Windows and after clicking a link the cursor stays as it is (regular or hand, depending if it is over a link or not)

Have you set ui.use_activity_cursor to true?

Sorry, no. I didn't think about that
After setting it, it works.

IMO much too much effort, just to get something that already worked in the past.