Closed Bug 1106527 Opened 9 years ago Closed 9 years ago

[UX] Need to replace e10s page loading spinner

Categories

(Firefox :: Tabbed Browser, defect)

40 Branch
x86
All
defect
Not set
normal

Tracking

()

RESOLVED FIXED
Firefox 42
Tracking Status
e10s m8+ ---
firefox42 --- fixed

People

(Reporter: m+mozilla, Assigned: gw280)

References

(Depends on 1 open bug)

Details

(Whiteboard: [ux])

Attachments

(2 files)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:37.0) Gecko/20100101 Firefox/37.0
Build ID: 20141130030213




Expected results:

Some good examples:

- http://jxnblk.com/loading/ (Loading..., i give up)
- http://codepen.io/TaniaLD/pen/oKxep
- http://codepen.io/scrapmac/pen/pgcJF
- http://codepen.io/scrapmac/pen/IJbBD
- http://codepen.io/thiesbrake/pen/bvLcI
- http://codepen.io/aurer/pen/jEGbA
- http://codepen.io/mikepro4/pen/yHjAz
- http://codepen.io/Mattykins/pen/wfJqk
- http://codepen.io/dghez/pen/Czuqn
Blocks: e10s
This isn't really an e10s bug at all.

Also see bug 1106936
tracking-e10s: --- → m8+
Component: Untriaged → Tabbed Browser
Summary: current e10s spinner is so 00s. please change it. → [UX] Need to replace e10s page loading spinner
This doesn't look like a bug, it looks like a request that we re-design the page loading spinner. Is there a UX or design person we can ask to do this? 

Or, if we don't have concrete plans to create a new spinner, we should either close this or remove m8 tracking flag and change it to + for post-release work.
Yep, that is an issue. The current spinner (and the frequency at which it is displayed) can cause e10s Firefox to feel slower than non-e10s Firefox. We obviously don't want that.

And since we now have a timeline to ship e10s, it's becoming kinda urgent.

Are there any restrictions on what we can show in the »tab busy« state, or could it essentially be anything that we can build with HTML/CSS?
Assignee: nobody → philipp
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(jmathies)
Flags: firefox-backlog+
OS: Mac OS X → All
Whiteboard: [ux]
Version: 37 Branch → 40 Branch
(In reply to Philipp Sackl [:phlsa] please use needinfo from comment #4)
> Yep, that is an issue. The current spinner (and the frequency at which it is
> displayed) can cause e10s Firefox to feel slower than non-e10s Firefox. We
> obviously don't want that.
> 
> And since we now have a timeline to ship e10s, it's becoming kinda urgent.
> 
> Are there any restrictions on what we can show in the »tab busy« state, or
> could it essentially be anything that we can build with HTML/CSS?

This is currently handled by css controlled by a property we set on the tab. We should stick with something light weight like this. We should avoid loading a separate document.

http://mxr.mozilla.org/mozilla-central/source/browser/base/content/tabbrowser.css#79
http://mxr.mozilla.org/mozilla-central/search?string=pendingpaint
Flags: needinfo?(jmathies)
Flags: qe-verify-
Attached patch WIP patchSplinter Review
Thanks for the clarification!
I figured out a good way to de-emphasize the spinner while not getting rid of it completely.

An even better experience would be fading in the spinner after a few ms delay. Unfortunately I wasn't able to test that with my limited knowledge of the Firefox code base, but perhaps you could help me out here :)
Attachment #8598193 - Flags: feedback?(jmathies)
Comment on attachment 8598193 [details] [diff] [review]
WIP patch

A couple issues:

- When this showed up I had to look for it. At first all I picked up on was a blank grey tab.
- The spinner was at the bottom of the tab and as such at the very bottom of the window. Easy to miss.

Overall I'm not seeing this as an improvement. I am not a ux person on the desktop team though so I can't sign off here anyway.
Attachment #8598193 - Flags: feedback?(jmathies) → feedback-
(In reply to Jim Mathies from comment #7)
> A couple issues:
> 
> - When this showed up I had to look for it. At first all I picked up on was a 
> blank grey tab.
> - The spinner was at the bottom of the tab and as such at the very bottom of 
> the window. Easy to miss.

That's exactly the point :)
The main point of the spinner is to show the user that the browser/tab has not frozen. That being said, whenever a user notices the spinner we are communicating that something takes time and we are effectively making them watch the clock. So the spinner should be discoverable when a user starts wondering whether something is wrong, but as little in your face as possible.

That's also why I asked about the ability to fade in the spinner. In the first few milliseconds of a blank screen, won't hurt too much, but if loading takes more than, say, half a second we want to have something that shows that the tab is not broken.
(In reply to Philipp Sackl [:phlsa] please use needinfo from comment #8)
> (In reply to Jim Mathies from comment #7)

> The main point of the spinner is to show the user that the browser/tab has
> not frozen.

But why? People were fine without an annoying spinner that just eats up a little more of the resource for more than a decade. Why is the sudden need for a spinner every time I open a new tab?
And why a white page by the way? A black one is less aggressive. O:)
(In reply to avada from comment #9)
> > The main point of the spinner is to show the user that the browser/tab has
> > not frozen.
> 
> But why? People were fine without an annoying spinner that just eats up a
> little more of the resource for more than a decade. Why is the sudden need
> for a spinner every time I open a new tab?

That's a very different thing. The spinner we're talking about here has nothing to do with loading pages, but with switching tabs when process separation (e10s) is enabled.


(In reply to Erwann Mest from comment #10)
> And why a white page by the way? A black one is less aggressive. O:)

Taking a casual look through the Alexa top 100 sites, most of them have white (or bright) backgrounds, so the transition from unloaded to loaded is more natural when starting with white in most cases.
(In reply to Philipp Sackl [:phlsa] please use needinfo from comment #11)
> That's a very different thing. The spinner we're talking about here has
> nothing to do with loading pages, but with switching tabs when process
> separation (e10s) is enabled.
> 

I know, that's what I was talking about. With my test profile (which I split from my main profile) most times I get the in-content spinner when I open a new tab. It's annoying
@phlsa thank you ;)
(In reply to Philipp Sackl [:phlsa] please use needinfo from comment #8)
> (In reply to Jim Mathies from comment #7)
> > A couple issues:
> > 
> > - When this showed up I had to look for it. At first all I picked up on was a 
> > blank grey tab.
> > - The spinner was at the bottom of the tab and as such at the very bottom of 
> > the window. Easy to miss.
> 
> That's exactly the point :)
> The main point of the spinner is to show the user that the browser/tab has
> not frozen. That being said, whenever a user notices the spinner we are
> communicating that something takes time and we are effectively making them
> watch the clock. So the spinner should be discoverable when a user starts
> wondering whether something is wrong, but as little in your face as possible.

Which is better, a blank tab that makes the browser look like it's frozen or an animated graphic indicating something is happening? I'd go for the spinner. However I am not a UX person, and I think you are, so if you want to take the spinner out, go for it provided you get the right sign off on the patch from whoever is in charge of Fx UX.

> That's also why I asked about the ability to fade in the spinner. In the
> first few milliseconds of a blank screen, won't hurt too much, but if
> loading takes more than, say, half a second we want to have something that
> shows that the tab is not broken.

From what I remember when we've experimented around with heavy animations for progress (fennec load indicator, desktop tab progress) animated elements have a bad habit of hurting load perf. That said with e10s a lot of the page load weight has been off lifted to the content process so maybe the impact will be less. We should find a way to test this.
I was thinking about this last night and I think I understand what you're going for in moving this down to the bottom of the window.

I have a large display with windows that rarely take up the screen but they do tend to be tall (~1400px on a 1600px display). With your patch the spinner isn't noticeable for me. Maybe the size of this graphic should be based on the size of content rather than set at a fixed width and height?
Please consider about high resolution spinner for HiDPI screen.
Picking this up again after a while...

After speaking with a few other members of the UX team, we should do a combination of two things:

1) When the spinner is showing, it should be more subtle, but we can keep it at the center. A spec is here: http://phlsa.github.io/fx-e10s-spinner/v2.html and the source code is here: https://github.com/phlsa/fx-e10s-spinner/blob/gh-pages/v2.html

2) The most annoying thing about the current version is when it briefly flashes when switching tabs. IIRC, we already keep showing the content of the previously selected tab for a few milliseconds if the content process isn't ready to display the new tab yet. We should increase that time to up to 400ms, which should get rid of a lot of the flashing.

NI Stephen for confirmation/review.
Flags: needinfo?(shorlander)
(In reply to Philipp Sackl [:phlsa] please use needinfo from comment #17)
> Picking this up again after a while...
> 
> After speaking with a few other members of the UX team, we should do a
> combination of two things:
> 
> 1) When the spinner is showing, it should be more subtle, but we can keep it
> at the center. A spec is here:
> http://phlsa.github.io/fx-e10s-spinner/v2.html and the source code is here:
> https://github.com/phlsa/fx-e10s-spinner/blob/gh-pages/v2.html
> 
> 2) The most annoying thing about the current version is when it briefly
> flashes when switching tabs. IIRC, we already keep showing the content of
> the previously selected tab for a few milliseconds if the content process
> isn't ready to display the new tab yet. We should increase that time to up
> to 400ms, which should get rid of a lot of the flashing.
> 
> NI Stephen for confirmation/review.

Looks nice! Suggested changes work for me.
Flags: needinfo?(shorlander)
Assignee: philipp → gwright
opted to generate a new animated png for the spinner from preloaders.net (where the original one came from) to avoid doing a scale operation.
Attachment #8630275 - Flags: review?(mconley)
Attachment #8630275 - Flags: review?(mconley) → review+
https://hg.mozilla.org/mozilla-central/rev/0e66ab5ef1fa
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 42
The issue was found on Firefox Nightly 37.0a1
Affected Build is : 20141201030207

Verifying this fix on latest Nightly 42.0a1
Fixed Build :   20150807030210
User Agent :	Mozilla/5.0 (Windows NT 6.1; rv:42.0) Gecko/20100101 Firefox/42.0
QA Whiteboard: [bugday-20150805]
No longer blocks: 1193668
Depends on: 1193668
Depends on: 1234006
I have this same unfortunate situation on Firefox 49.0.1 (on Windows).
You need to log in before you can comment on or make changes to this bug.