Closed Bug 482985 Opened 15 years ago Closed 8 years ago

Loading/busy/spinning mouse indicator/pointer/icon missing

Categories

(Firefox :: General, defect)

Product:
Firefox
Component:
General
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME
Tracking Flags:
Tracking Status
status1.9.1 --- wontfix

People

(Reporter: pkc, Assigned: mstange)

References

(Depends on 1 open bug)

Details

(Keywords: common-issue-, regression, uiwanted, Whiteboard: [parity-chrome][parity-IE])

Attachments

(3 files, 1 obsolete file)

Laughable Addon for the impatient like me
3.18 KB, application/x-xpinstall
Details
implement ui.use_activity_cursor (checked in)
4.48 KB, patch
bzbarsky
: review+
Details | Diff | Splinter Review
adjust pref defaults
1.10 KB, patch
bzbarsky
: review+
faaborg
: ui-review-
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2a1pre) Gecko/20090305 Firefox/3.2a1pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2a1pre) Gecko/20090305 Firefox/3.2a1pre

As indicated in Bug 481359, it has been arbitrarily decided that the loading cursor on data transfer was bad and it was altogether removed.

However this was actually useful for all those that do not use the status bar and throbber(which are actually harder to notice, especially since usually when you click a link you have your eyes on the link you click, not on the throbber).

It was in many ways very useful as it indicated actual network activity and hence that removal would need to be made an option or if it is thought to be in the wrong place, recoded.

Reproducible: Always
Blocks: 481359
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression
Product: Firefox → Core
QA Contact: general → general
Version: unspecified → Trunk
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....
Product: Core → Firefox
QA Contact: general → general
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.
Product: Firefox → Core
QA Contact: general → general
(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.
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.
Flags: wanted1.9.1?
Keywords: uiwanted
Whiteboard: [parity-chrome]
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.
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!
Keywords: common-issue?
Summary: Removal of loading mouse cursor on data transfer → Loading/busy/spinning mouse indicator/pointer/icon missing
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?
Are there any plans to fix this on non-OSX systems in 3.5.1? Or make it at least configurable via about:config?
Flags: wanted1.9.1? → wanted1.9.1.x?
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!
Attached patch only remove on OS X (obsolete) — — Splinter Review 
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.
Attachment #388666 - Flags: ui-review?(beltzner)
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.
Flags: blocking1.9.2?
(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.
Flags: blocking1.9.2?
Product: Core → Firefox
QA Contact: general → general
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.
Yes, backing out a code bit that replaced a problem by another was an issue. Backing out the patch until there is an actual replacement code would actually seem like a good idea. I'm not sure about you, but when something's ugly but useful, I do not actually remove it just because it's ugly with an indefinite wait for a replacement, I wait for the replacement to come in and then remove the ugly bit.
Attachment #388666 - Flags: ui-review?(beltzner) → review-
(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.

As a Mac OS X user looking for the load cursor to be reinstated ....... NO! It needs to go back in for all platforms.
Flags: blocking-firefox3.6?
Since 2.0b1 this bug affects Seamonkey as well. 
I really want to have the hourglass back.
status1.9.1: --- → ?
Flags: wanted1.9.1.x?
I also have to agree that it was a mistake to remove it. And there should be a simple option to enable it again.

I use WinXP Pro

For me, visually disabled, this is a vital indicator. It is very hard for me to find the "active" tab and try to see if the little "busy" icon is moving. The "ANY" page indicator was larger and in a fixed location. One always knew what was going on with the old functionality. Now we don't.

It is also important for me when multiple pages are re-loading (sometimes automatically on somewebsites, e.g. every 30-60 seconds or so) to note when <b>ANY</b> web page is being updated, even if its tab is not currently visible in the list of tabs bar.

I simply don't understand why someone decided the "general" browser page loading activity icon should be taken away (unless result of Firefox infringing on some other browser's Intellectual Property threat)

Reducing like that the functionality of a key feature makes no sense, especially when NO way to re-instate the feature is provided, or if it is, it certainly isn't obvious nor easy.
I should have added that being visually disabled, when you use the mouse wheel to increase the size of the text on a page being viewed, the tab list is NOT similarly increased. But one does NOT generally want all the "background"default text size increased anyway because it then takes up too much room on the screen leaving virtually no room for the actual page content. 

The presence of the single larger, static location webpage loading activity icon was thus much more helpful to the visually impaired.
(In reply to comment #43)
> For me, visually disabled, this is a vital indicator. It is very hard for me to
> find the "active" tab and try to see if the little "busy" icon is moving. The
> "ANY" page indicator was larger and in a fixed location. One always knew what
> was going on with the old functionality. Now we don't.

That doesn't sound like you're talking about the busy _cursor_. Do you perhaps mean the throbber which used to be in the upper right corner? It was removed by default, but you can easily reenable it by right-clicking on the menu bar and choosing "Customize", then dragging it wherever you want it.

This bug is about changing the cursor to inidicate activity, which many people (including myself) want back too.
This is a very simple addon that just adds a tiny amount of CSS to the old page (before the new page start loading) when a link is clicked (or such) which makes all elements on the page display the progress cursor.

I have submitted it here because I dont think its a good solution in any way and could easily make page rendering problems. Feel free to take on the idea and submit a real addon.
(In reply to comment #46)
> I have submitted it here because I dont think its a good solution in any way
> and could easily make page rendering problems. Feel free to take on the idea
> and submit a real addon.

Works awesomely for my current needs (activity indicator while in full screen).  Thanks!
This hardly works as a real solution though.
Plus it will not work properly on AJAX content.
> This hardly works as a real solution though.
I know this is not a solution in any way. Interacting with the actual source of the webpages was not my original aim but I could not work out how to just apply the cursor change on the tab/browser object. And if the cursor setting is set in the element's style attribute then the cursor will not change anyway with this.

> Plus it will not work properly on AJAX content.
For the AJAX page activity I think that should be up to the actual creators of the AJAX page since they may not want the cursor flickering while their scripts load extra parts for display.
I personally disagree there. Having ajax do things in your back is not really nice. If JS is waiting on data loading I'd like to be aware of it rather than get impatient and redo an action that's just being done.
If anything if creators do not want any activity to be displayed they should enforce a non-loading cursor during loads, not the opposite.
i vote for the busy cursor as i need it badly. i use a small batch to do some work in our company intranet. this batch is waiting until the page is fully loaded. the only way for me to indicate was the busy mouse indicator. i had to downgrade to firefox 3.0.xxx. 

this i very disappointing. 
i ever thought "it's not a bug it's a feature" is only relating to microsoft...
It would be interesting if any hacker other than Mr. Hugh showed interest in this issue... it really isn't as trivial as it was first painted to be.
If bug 309547 ever got fixed, that would make it trivial for an extension to restore the loading mouse pointer, since it could just force it on in response to the same event that turns the throbber on and off.
1 report of this in the past month.  Not common request from support users.
Keywords: common-issue? → common-issue-
Won't block 3.6 on this, and I don't think we want to back-port any change here.

The cursor was removed because the cursor is meant to indicate that the system is busy loading a resource and the user can't interact with it. As others have mentioned, if we can fix our code so that we can understand at what point a user can interact with the loaded content, and only show the "loading" cursor between the point when a new resource is loaded and when the user can interact with it, I'm fine to put it back in.

Otherwise, it's better out than in, I'm afraid.
status1.9.1: ? → wontfix
Flags: blocking-firefox3.6? → blocking-firefox3.6-
(In reply to comment #55)
> The cursor was removed because the cursor is meant to indicate that the system
> is busy loading a resource and the user can't interact with it.

CSS distinguishes between "wait" and "progress", both of which we implement. So if that was the motivation (this wasn't clear to me until now), then the cursor should have been replaced with one that doesn't indicate that the user can't interact with the app, rather than being removed.
I'm sorry but I will have to disagree here. If the icon is wrong on OS X, then it should just have been changed there, not unilaterally removed.
In my opinion, if anything it(the cursor) should just change when there's actual meaningful network activity, such as ajax loading or the page itself loading. That kind of transfer usually indicates to the user he should wait, which is not the case when waiting for images.

In any case if this is not going to be backported then there's a clear need that some of the "gurus" should at least *suggest* ways to restore something similar to the old behavior in an extension.

And I'd like to point again that both opera and safari have the cursor change on load while loading pages. That behavior is in *no* way odd. And frankly it's the kind of thing the user should actually have a choice on.
Is it that hard to add an about:config option for it?
Why FORCE users to have a different experience ONLY in Firefox 3.5? As it was mentioned before, Windows usually displays the busy cursor while content is loading.

> The cursor was removed because the cursor is meant to indicate that the system
> is busy loading a resource and the user can't interact with it.
Why not use the mixed busy+normal cursor(no idea how it's called, I mean the one which has a regular arrow but a small busy icon below it) in this case?
Whiteboard: [parity-chrome] → [parity-chrome][parity-IE]
Nevermind on the second part of my comment, just noticed it already uses this cursor.
(In reply to comment #59)
> Nevermind on the second part of my comment, just noticed it already uses this
> cursor.

In that case, "The cursor was removed because the cursor is meant to indicate that [...] the user can't interact with it" doesn't make sense.
(In reply to comment #56)
> the cursor
> should have been replaced with one that doesn't indicate that the user can't
> interact with the app, rather than being removed.

Indeed.  As said before, the cursor is sometimes the only UI indication that
something is going on.  If the cursor doesn't change, then the obvious
conclusion is that nothing is going on.  So if I click on a link, and nothing
is going on, what do I do?  I click again.  And again.  Well, still nothing. 
Let's double-click then?  Nope, sill nothing.  Middle-click?   Nope. 
Middle-double-click?

And when the user leaves full-screen, there's five tabs of the same slow
loading page (bonus points if the page loads some real-time report with lots of
complicated math on massive datasets).

I had to fight to make some of my users understand that the cursor tells them
if their click succeeded, and there's no need to click five time on a link,
because it won't make it load any faster.  And now the cursor doesn't change
anymore...
Attachment #388666 - Flags: ui-review?(beltzner)
Attachment #388666 - Flags: review?(bzbarsky)
Attachment #388666 - Flags: review-
Is this just backing out bug 481359 but adding ifdefs?

If so, I'd prefer a pref, not ifdefs.
(In reply to comment #62)
> Is this just backing out bug 481359 but adding ifdefs?

Yes, since it seems that bug 481359 happened just because the cursor on OS X is too bold and misleading.

> If so, I'd prefer a pref, not ifdefs.

Markus, can you do that?
(In reply to comment #57)
> In any case if this is not going to be backported then there's a clear need
> that some of the "gurus" should at least *suggest* ways to restore something
> similar to the old behavior in an extension.

Yes... why are the coders who removed this not bothering to offer support? They surely understand the function enough to have slashed it.
Comment on attachment 388666 [details] [diff] [review]
only remove on OS X

Per comment 37 (see the part about platform ifdefs there) and comment 62
Attachment #388666 - Flags: review?(bzbarsky) → review-
(In reply to comment #63)
> (In reply to comment #62)
> > Is this just backing out bug 481359 but adding ifdefs?
> 
> Yes, since it seems that bug 481359 happened just because the cursor on OS X is
> too bold and misleading.
> 
> > If so, I'd prefer a pref, not ifdefs.
> 
> Markus, can you do that?

Would be awesome to have such a preference. Firefox has 3 other indications for the loading (tab, bottom left and right), so I did not notice the change for some time. The Sugar browser (http://dev.sugarlabs.org/ticket/851) does not have such indicators, so the spinning cursor was always a great way to see if the browser was busy loading.

+1 for this pref
Big +1; this is a constant problem for me.  While loading this very page, I clicked the link twice: when the cursor didn't immediately change to "loading" after clicking the link, I automatically clicked on it again.  This is fundamental, standard UI that every other Windows browser has (except for Safari--which itself says something).
(In reply to comment #63)
> > If so, I'd prefer a pref, not ifdefs.
> 
> Markus, can you do that?

OK. Any idea on a good name? ui.use_progress_cursor?
Assignee: nobody → mstange
ui.use_activity_cursor maybe?(since it's a cursor on active transfer rather than on progress)
Either way, glad to see things moving.
Uses pref ui.use_activity_cursor, defaulting to false.
Attachment #388666 - Attachment is obsolete: true
Attachment #401141 - Flags: ui-review?(beltzner)
Attachment #401141 - Flags: review?(bzbarsky)
Attachment #388666 - Flags: ui-review?(beltzner)
Comment on attachment 401141 [details] [diff] [review]
implement ui.use_activity_cursor (checked in)

Looks good, but should there be an ifdef here in all.js enabling the cursor for non-mac?
Attachment #401141 - Flags: review?(bzbarsky) → review+
I would tend to agree with that. The original bug report for the removal specified clearly spinner, indicating macos x. Same with the browser reports.
Let's have Beltzner make the decision. I don't have an opinion on it.
Why is this waiting for ui-review if it doesn't change behavior? This could land as is, as far as I can see, and either way we should get a patch up for ui-review that fixes this by default for Windows and Linux, given the increased indications that something went wrong in bug 481359.
You're right, this can land as-is. Feel free to do so.
Comment on attachment 401141 [details] [diff] [review]
implement ui.use_activity_cursor (checked in)

http://hg.mozilla.org/mozilla-central/rev/2d7916087cc3
Attachment #401141 - Attachment description: v2 → implement ui.use_activity_cursor (checked in)
Attachment #401141 - Flags: ui-review?(beltzner) → approval1.9.2?

        Attachment #401212 -
        Flags: ui-review?(beltzner)

        Attachment #401212 -
        Flags: review?(bzbarsky)

    
    

    
  
Pardon a layman, but am I to understand that this will probably land in the 3.6 Release Candidate and I will be able to get on with my work now that sensible coders have restored a feature that should have never been removed?

        Attachment #401212 -
        Flags: review?(bzbarsky) → review+

    
  
Depends on: 517272

    
    

    
  
Hi, any chance this gets into 1.9.1?
Depends on: 517768

    
    

    
  
(In reply to comment #79)
> Hi, any chance this gets into 1.9.1?

This has been WONTFIX'd on 1.9.1.  So the only way people can have this on 1.9.1 is if somebody creates an extension.  =/

    
    

    
  
Isn't the WONTFIX from early times when devs didn't want it back at all?

    
    

    
  
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.

    
  
Blocks: 517272
No longer depends on: 517272

    
    

    
  
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...
Depends on: 534538

    
    

    
  
Comment on attachment 401141 [details] [diff] [review]
implement ui.use_activity_cursor (checked in)

Don't think we want to take this on the branch without bug 534538 addressed.

        Attachment #401141 -
        Flags: approval1.9.2?

    
    

    
  
Comment on attachment 401212 [details] [diff] [review]
adjust pref defaults

With ui.use_activity_cursor set true this regresses bug 487382

    
    

    
  
Comment on attachment 401212 [details] [diff] [review]
adjust pref defaults

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

    
  
Depends on: 552193

    
  
Blocks: 573385

    
  
Blocks: 537015

    
    

    
  
(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

    
  
Blocks: 603594

    
    

    
  
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;

    
  
No longer blocks: 603594

    
    

    
  
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.

    
  

        Attachment #401212 -
        Flags: ui-review?(mbeltzner) → ui-review?(faaborg)

    
    

    
  
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.)

    
  
Depends on: 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

    
  
Blocks: 659573
No longer depends on: 659573

    
    

    
  
Comment on attachment 401212 [details] [diff] [review]
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).

        Attachment #401212 -
        Flags: ui-review?(faaborg) → ui-review-

    
    

    
  
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.

    
    

    
  
This bug has been marked for Regression and or Closure
Version 	46.0.1
Build ID 	20160502172042
ui.use_activity_cursor (T/F) works for me
Considering this I will close this as Resolved-WFM
Feel free to reopen if issue is still a concern.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WORKSFORME

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: