Mouse cursor does not change upon page load/refresh
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Mozilla Firefox |
Invalid
|
Medium
|
|||
firefox-3.5 (Ubuntu) |
Triaged
|
Low
|
Unassigned |
Bug Description
Description: Ubuntu 9.04
Release: 9.04
$ apt-cache policy firefox-3.5
firefox-3.5:
Installed: 3.5+nobinonly-
Candidate: 3.5+nobinonly-
Version table:
*** 3.5+nobinonly-
500 http://
100 /var/lib/
3.
500 http://
Upon any action requiring page load/reload etc mouse cursor does not change, the only visual feedback that the program is busy is animation instead of icon on the page tab.
Expected behavior: upon loading page mouse cursor should be change to provide visual feedback to the user.
In Mozilla Bugzilla #482985, Bzbarsky (bzbarsky) wrote : | #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. Of course an extension can do the same.
I have no idea why anyone would want to differentiate between active and inactive tabs, though....
In Mozilla Bugzilla #482985, Pkc (pkc) wrote : | #3 |
Usually to find out which pages have loaded and are ready to be looked at.
In Mozilla Bugzilla #482985, Dao (dao) wrote : | #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.
In Mozilla Bugzilla #482985, Beltzner (beltzner) wrote : | #5 |
(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.
In Mozilla Bugzilla #482985, Pkc (pkc) wrote : | #6 |
Changing the cursor is not the issue. I believe actually knowing when to do it is more of the issue here.
In Mozilla Bugzilla #482985, Gavin Sharp (gavin-sharp) wrote : | #7 |
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 Mozilla Bugzilla #482985, Neil-httl (neil-httl) wrote : | #8 |
(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.
In Mozilla Bugzilla #482985, Steve-england (steve-england) wrote : | #9 |
*** Bug 490603 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #482985, Highmind63 (highmind63) wrote : | #10 |
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.
In Mozilla Bugzilla #482985, Mstange-themasta (mstange-themasta) wrote : | #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.
In Mozilla Bugzilla #482985, Pkc (pkc) wrote : | #12 |
I personally think that since things were originally reported by OS X users, it should only be removed there.
In Mozilla Bugzilla #482985, Highmind63 (highmind63) wrote : | #13 |
*** Bug 497238 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #482985, Maksym-mozul (maksym-mozul) wrote : | #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.
In Mozilla Bugzilla #482985, Supernova00 (supernova00) wrote : | #15 |
(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!
In Mozilla Bugzilla #482985, Supernova00 (supernova00) wrote : | #16 |
*** Bug 501750 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #482985, Adrian (thiefmaster) wrote : | #17 |
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.
In Mozilla Bugzilla #482985, Adrian (thiefmaster) wrote : | #18 |
Is there any easy way (i.e. without recompiling) to re-enable the loading cursor manually?
In Mozilla Bugzilla #482985, Pkc (pkc) wrote : | #19 |
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.
In Mozilla Bugzilla #482985, Adrian (thiefmaster) wrote : | #20 |
I recompiled with this [http://
Alexey Balmashnov (a.balmashnov) wrote : | #21 |
Description: Ubuntu 9.04
Release: 9.04
$ apt-cache policy firefox-3.5
firefox-3.5:
Installed: 3.5+nobinonly-
Candidate: 3.5+nobinonly-
Version table:
*** 3.5+nobinonly-
500 http://
100 /var/lib/
3.
500 http://
Upon any action requiring page load/reload etc mouse cursor does not change, the only visual feedback that the program is busy is animation instead of icon on the page tab.
Expected behavior: upon loading page mouse cursor should be change to provide visual feedback to the user.
In Mozilla Bugzilla #482985, Jmjeffery (jmjeffery) wrote : | #22 |
*** Bug 502611 has been marked as a duplicate of this bug. ***
Brian (kravitz-brian) wrote : | #23 |
I can confirm this is happening for me too. I'm expecting to see the busy mouse animation when a page is loading, but it's just the normal cursor the whole time.
Changed in firefox-3.5 (Ubuntu): | |
importance: | Undecided → Low |
status: | New → Confirmed |
Micah Gersten (micahg) wrote : | #24 |
Thank you for your bug report. This bug has been reported to the developers of the software. You can track it and make comments at:
https:/
Changed in firefox-3.5 (Ubuntu): | |
status: | Confirmed → Triaged |
Changed in firefox: | |
status: | Unknown → New |
In Mozilla Bugzilla #482985, Adrian (thiefmaster) wrote : | #25 |
Are there any plans to fix this on non-OSX systems in 3.5.1? Or make it at least configurable via about:config?
In Mozilla Bugzilla #482985, Lad-of-bodom (lad-of-bodom) wrote : | #26 |
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.
In Mozilla Bugzilla #482985, Hughnougher (hughnougher) wrote : | #27 |
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.
In Mozilla Bugzilla #482985, Bartschc-web (bartschc-web) wrote : | #28 |
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!
In Mozilla Bugzilla #482985, Mstange-themasta (mstange-themasta) wrote : | #29 |
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.
In Mozilla Bugzilla #482985, Syskin (syskin) wrote : | #30 |
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.
In Mozilla Bugzilla #482985, Mstange-themasta (mstange-themasta) wrote : | #31 |
OK, but then somebody else will have to do that. I don't know how and I don't want to do it.
In Mozilla Bugzilla #482985, Elmar-ludwig (elmar-ludwig) wrote : | #32 |
(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.
In Mozilla Bugzilla #482985, Adrian (thiefmaster) wrote : | #33 |
> 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 Mozilla Bugzilla #482985, Dao (dao) wrote : | #34 |
(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 Mozilla Bugzilla #482985, Dao (dao) wrote : | #35 |
(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 Mozilla Bugzilla #482985, M-theuntethered (m-theuntethered) wrote : | #36 |
(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 Mozilla Bugzilla #482985, Nicolas Briche (nbriche) wrote : | #37 |
(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 Mozilla Bugzilla #482985, Elmar-ludwig (elmar-ludwig) wrote : | #38 |
(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.
In Mozilla Bugzilla #482985, Bzbarsky (bzbarsky) wrote : | #39 |
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.
In Mozilla Bugzilla #482985, Bzbarsky (bzbarsky) wrote : | #40 |
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.
In Mozilla Bugzilla #482985, Pkc (pkc) wrote : | #41 |
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.
In Mozilla Bugzilla #482985, Bslwannabe (bslwannabe) wrote : | #42 |
(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.
In Mozilla Bugzilla #482985, longsonr (longsonr) wrote : | #43 |
*** Bug 506610 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #482985, 100-59706 (100-59706) wrote : | #44 |
Since 2.0b1 this bug affects Seamonkey as well.
I really want to have the hourglass back.
In Mozilla Bugzilla #482985, longsonr (longsonr) wrote : | #45 |
*** Bug 507793 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #482985, John2864 (john2864) wrote : | #46 |
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.
In Mozilla Bugzilla #482985, John2864 (john2864) wrote : | #47 |
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 Mozilla Bugzilla #482985, Oliver-volatilevoid (oliver-volatilevoid) wrote : | #48 |
(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.
In Mozilla Bugzilla #482985, Hughnougher (hughnougher) wrote : | #49 |
Created an attachment (id=394250)
Laughable Addon for the impatient like me
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 Mozilla Bugzilla #482985, Nicolas Briche (nbriche) wrote : | #50 |
(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!
In Mozilla Bugzilla #482985, Pkc (pkc) wrote : | #51 |
This hardly works as a real solution though.
Plus it will not work properly on AJAX content.
In Mozilla Bugzilla #482985, Hughnougher (hughnougher) wrote : | #52 |
> 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.
In Mozilla Bugzilla #482985, Pkc (pkc) wrote : | #53 |
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.
In Mozilla Bugzilla #482985, Elektromotive (elektromotive) wrote : | #54 |
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...
In Mozilla Bugzilla #482985, Lad-of-bodom (lad-of-bodom) wrote : | #55 |
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.
In Mozilla Bugzilla #482985, Neil-httl (neil-httl) wrote : | #56 |
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.
In Mozilla Bugzilla #482985, Cwwmozilla (cwwmozilla) wrote : | #57 |
1 report of this in the past month. Not common request from support users.
In Mozilla Bugzilla #482985, Beltzner (beltzner) wrote : | #58 |
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.
In Mozilla Bugzilla #482985, Dao (dao) wrote : | #59 |
(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.
In Mozilla Bugzilla #482985, Pkc (pkc) wrote : | #60 |
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.
In Mozilla Bugzilla #482985, Adrian (thiefmaster) wrote : | #61 |
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?
In Mozilla Bugzilla #482985, Adrian (thiefmaster) wrote : | #62 |
Nevermind on the second part of my comment, just noticed it already uses this cursor.
In Mozilla Bugzilla #482985, Dao (dao) wrote : | #63 |
(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 Mozilla Bugzilla #482985, Nicolas Briche (nbriche) wrote : | #64 |
(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-
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...
In Mozilla Bugzilla #482985, Bzbarsky (bzbarsky) wrote : | #65 |
Is this just backing out bug 481359 but adding ifdefs?
If so, I'd prefer a pref, not ifdefs.
In Mozilla Bugzilla #482985, Dao (dao) wrote : | #66 |
(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 Mozilla Bugzilla #482985, Lad-of-bodom (lad-of-bodom) wrote : | #67 |
(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.
In Mozilla Bugzilla #482985, Bzbarsky (bzbarsky) wrote : | #68 |
(From update of attachment 388666)
Per comment 37 (see the part about platform ifdefs there) and comment 62
Sami Mäkinen (sami-makinen-helsinki) wrote : | #69 |
This is a better bug for this issue:
https:/
Please vote for it, show that there is interest in getting this issue fixed or reverted.
In Mozilla Bugzilla #482985, Simon-schampijer (simon-schampijer) wrote : | #70 |
(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://
+1 for this pref
In Mozilla Bugzilla #482985, Glenn Maynard (glenn-zewt) wrote : | #71 |
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 Mozilla Bugzilla #482985, Mstange-themasta (mstange-themasta) wrote : | #72 |
(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_
In Mozilla Bugzilla #482985, Pkc (pkc) wrote : | #73 |
ui.use_
Either way, glad to see things moving.
In Mozilla Bugzilla #482985, Mstange-themasta (mstange-themasta) wrote : | #74 |
Created an attachment (id=401141)
v2
Uses pref ui.use_
In Mozilla Bugzilla #482985, Bzbarsky (bzbarsky) wrote : | #75 |
(From update of attachment 401141)
Looks good, but should there be an ifdef here in all.js enabling the cursor for non-mac?
In Mozilla Bugzilla #482985, Pkc (pkc) wrote : | #76 |
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.
In Mozilla Bugzilla #482985, Mstange-themasta (mstange-themasta) wrote : | #77 |
Let's have Beltzner make the decision. I don't have an opinion on it.
In Mozilla Bugzilla #482985, Dao (dao) wrote : | #78 |
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.
In Mozilla Bugzilla #482985, Mstange-themasta (mstange-themasta) wrote : | #79 |
You're right, this can land as-is. Feel free to do so.
In Mozilla Bugzilla #482985, Dao (dao) wrote : | #80 |
(From update of attachment 401141)
http://
In Mozilla Bugzilla #482985, Dao (dao) wrote : | #81 |
Created an attachment (id=401212)
adjust pref defaults
In Mozilla Bugzilla #482985, Lad-of-bodom (lad-of-bodom) wrote : | #82 |
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?
In Mozilla Bugzilla #482985, Tomeu Vizoso (tomeu) wrote : | #83 |
Hi, any chance this gets into 1.9.1?
In Mozilla Bugzilla #482985, Engamer01 (engamer01) wrote : | #84 |
(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. =/
In Mozilla Bugzilla #482985, Adrian (thiefmaster) wrote : | #85 |
Isn't the WONTFIX from early times when devs didn't want it back at all?
In Mozilla Bugzilla #482985, Lad-of-bodom (lad-of-bodom) wrote : | #86 |
It is, indeed. It relates back to the first days of the bug. It should be re-evaluated...
In Mozilla Bugzilla #482985, Rafal-maj-it (rafal-maj-it) wrote : | #87 |
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.
LimCore (limcore) wrote : | #88 |
I confirm this, on Ubuntu 9.10
LimCore (limcore) wrote : | #89 |
Can't we fix this by custom patch without waiting for upstream? This is really very not comfortable to use now.
In Mozilla Bugzilla #482985, Bslwannabe (bslwannabe) wrote : | #90 |
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.
In Mozilla Bugzilla #482985, Rafal-maj-it (rafal-maj-it) wrote : | #91 |
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
In Mozilla Bugzilla #482985, Adrian (thiefmaster) wrote : | #92 |
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...
Micah Gersten (micahg) wrote : | #93 |
Changing Upstream bugwatch to main bug
Changed in firefox: | |
status: | New → Unknown |
Changed in firefox: | |
status: | Unknown → Confirmed |
In Mozilla Bugzilla #482985, Gavin Sharp (gavin-sharp) wrote : | #94 |
(From update of attachment 401141)
Don't think we want to take this on the branch without bug 534538 addressed.
In Mozilla Bugzilla #482985, John-p-baker (john-p-baker) wrote : | #95 |
(From update of attachment 401212)
With ui.use_
In Mozilla Bugzilla #482985, Neil-httl (neil-httl) wrote : | #96 |
(From update of attachment 401212)
I don't suppose someone else exists who can do this ui-review more quickly?
In Mozilla Bugzilla #482985, Lad-of-bodom (lad-of-bodom) wrote : | #97 |
Where are we on this one? Will it make it in time for 3.7? Or maybe under the Lorentz model...
In Mozilla Bugzilla #482985, Adrian (thiefmaster) wrote : | #98 |
What's the current state of this? Did the about:config option make it into the current release version?
In Mozilla Bugzilla #482985, Engamer01 (engamer01) wrote : | #99 |
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.
In Mozilla Bugzilla #482985, Rob (rob1weld) wrote : | #100 |
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://
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
Changed in firefox: | |
importance: | Unknown → Medium |
In Mozilla Bugzilla #482985, Simon-schampijer (simon-schampijer) wrote : | #101 |
(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://
[2] http://
[3] https:/
[4] http://
In Mozilla Bugzilla #482985, Paul (sabret00the) wrote : | #102 |
Isn't this a dupe of bug 481359?
In Mozilla Bugzilla #482985, Dao (dao) wrote : | #103 |
(In reply to comment #95)
> Isn't this a dupe of bug 481359?
No...
In Mozilla Bugzilla #482985, Paul (sabret00the) wrote : | #104 |
(In reply to comment #96)
As so this isn't adding back what that removed? Sorry was just attempting to clarify.
In Mozilla Bugzilla #482985, Eevee-mozilla (eevee-mozilla) wrote : | #105 |
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.
In Mozilla Bugzilla #482985, Glenn Maynard (glenn-zewt) wrote : | #106 |
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.
In Mozilla Bugzilla #482985, Thomas Mitterfellner (tomm-sbox) wrote : | #107 |
I'm pleased to see that setting ui._use_
In Mozilla Bugzilla #482985, Per Ångström (autark) wrote : | #108 |
I'm running trunk Minefield/Linux 64-bit, with ui._use_
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.
In Mozilla Bugzilla #482985, Thomas Mitterfellner (tomm-sbox) wrote : | #109 |
Per, you're right. I am missing these busy cursor versions too, because it's sometimes confusing: has my click been accepted or not?
In Mozilla Bugzilla #482985, Bretonf (bretonf) wrote : | #110 |
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_
Is there any extension to bring back? Is it planned for a future Firefox version?
In Mozilla Bugzilla #482985, Engamer01 (engamer01) wrote : | #111 |
(In reply to comment #103)
> I heard this was added back with a preference (ui.use_
> 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://
In Mozilla Bugzilla #482985, Vova (vovaolar) wrote : | #112 |
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.
In Mozilla Bugzilla #482985, Engamer01 (engamer01) wrote : | #113 |
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.
In Mozilla Bugzilla #482985, Bslwannabe (bslwannabe) wrote : | #114 |
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-
In Mozilla Bugzilla #482985, Glenn Maynard (glenn-zewt) wrote : | #115 |
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_
In Mozilla Bugzilla #482985, Bslwannabe (bslwannabe) wrote : | #116 |
Several of us wanted (want!) it on Mac OS X too. Setting ui.use_
In Mozilla Bugzilla #482985, Vova (vovaolar) wrote : | #117 |
In Mozilla Bugzilla #482985, Thomas Mitterfellner (tomm-sbox) wrote : | #118 |
(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:/
In Mozilla Bugzilla #482985, Dao (dao) wrote : | #119 |
*** Bug 659353 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #482985, Faaborg (faaborg) wrote : | #120 |
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).
In Mozilla Bugzilla #482985, Glenn Maynard (glenn-zewt) wrote : | #121 |
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".
In Mozilla Bugzilla #482985, Thomas Mitterfellner (tomm-sbox) wrote : | #122 |
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!
In Mozilla Bugzilla #482985, David-balazic (david-balazic) wrote : | #123 |
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)
In Mozilla Bugzilla #482985, Thomas Mitterfellner (tomm-sbox) wrote : | #124 |
Have you set ui.use_
In Mozilla Bugzilla #482985, David-balazic (david-balazic) wrote : | #125 |
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.
In Mozilla Bugzilla #482985, Mfunches (mfunches) wrote : | #126 |
This bug has been marked for Regression and or Closure
Version 46.0.1
Build ID 20160502172042
ui.use_
Considering this I will close this as Resolved-WFM
Feel free to reopen if issue is still a concern.
Changed in firefox: | |
status: | Confirmed → Invalid |
In Mozilla Bugzilla #482985, Dmehic (dmehic) wrote : | #127 |
*** Bug 531058 has been marked as a duplicate of this bug. ***
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.