1399891 - [meta] Suppress the Windows »waiting« cursor when possible

Status: NEW

(Firefox :: General, enhancement, P3)

Description

[(Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo]

Attachment: Windows waiting cursor

This might actually be a meta bug...

One thing that consistently came up in our benchmarking user studies was that the Windows »waiting« cursor (the one with the little circular loading indicator next to it, see attachment) made users perceive Firefox as slow.
As I understand it, in most cases users didn't even know what exactly they were supposed to wait for. And in the cases where it was clear (like page load), we usually also had a different progress indicator that was more specific.

We should therefore look into reducing the instances in which this generic indicator is shown. I assume that in many cases we can just drop it, but there might also be some where we want to think about a custom indicator. This is pending investigation.

Comment 1

[Jim Mathies [:jimm]]

Who's doing the investigating here, can we get them assigned to this bug and a priority set please? Thanks!

Comment 2

[Panos Astithas (he/him) [:past] (please ni?)]

Jim, with the [reserve-photon-performance][triage] tags set, the photon team will prioritize this bug in their next meeting.

Comment 3

[Florian Quèze [:florian]]

Philipp, is this about the cursor behavior during startup, or do you know of cases where this cursor is shown after Firefox has finished starting?

This cursor is the "appstarting" cursor, it's displayed automatically by Windows when an application is starting, and disappears (is replaced with the normal cursor) when the application starts pulling events from the event loop.

During startup, what I typically see is:
- the appstarting cursor is there for a little while.
- then the appstarting cursor 'blinks' a couple times (maybe 2 or 3 times), where by "blink" I mean it's replaced with the normal cursor, and then back to appstarting cursor.
- about when the dock icon starts appearing, the cursor switches to the "wait" cursor (no arrow, just the circular indicator).
- this wait cursor disappears when we are mostly done loading the chrome (ie. tab bar and toolbar are there with images displayed, but about:home hasn't loaded yet).
- the cursor still changes a couple times between apploading and normal.

So... it seems to me that it would feel nicer if we could reduce the number of cursor changes we do during startup, but I'm not sure if this is what you had in mind for this bug :-).

Comment 4

[(Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo]

(In reply to Florian Quèze [:florian] from comment #3)
Thanks for investigating!

> Philipp, is this about the cursor behavior during startup, or do you know of
> cases where this cursor is shown after Firefox has finished starting?
Yes, I have seen it myself in other cases and I remember user reports stating the same. I can't tell you the exact scenario, unfortunately - I just remember that it felt arbitrary. Could this be triggered by apps launching in the background (possibly automatically)? Or maybe from a content/plugin process starting?

> This cursor is the "appstarting" cursor, it's displayed automatically by
> Windows when an application is starting, and disappears (is replaced with
> the normal cursor) when the application starts pulling events from the event
> loop.
Aha! :)

> During startup, what I typically see is:
> - the appstarting cursor is there for a little while.
> - then the appstarting cursor 'blinks' a couple times (maybe 2 or 3 times),
> where by "blink" I mean it's replaced with the normal cursor, and then back
> to appstarting cursor.
> - about when the dock icon starts appearing, the cursor switches to the
> "wait" cursor (no arrow, just the circular indicator).
> - this wait cursor disappears when we are mostly done loading the chrome
> (ie. tab bar and toolbar are there with images displayed, but about:home
> hasn't loaded yet).
> - the cursor still changes a couple times between apploading and normal.
> 
> So... it seems to me that it would feel nicer if we could reduce the number
> of cursor changes we do during startup, but I'm not sure if this is what you
> had in mind for this bug :-).
Yeah, that sounds like a good general direction (for startup). I'll watch out for non-startup versions of this cursor and see if I can describe a scenario a little better. Any tips on how to do that are highly appreciated!

Comment 5

[Florian Quèze [:florian]]

(In reply to (Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo from comment #4)
> Could this be triggered by apps
> launching in the background (possibly automatically)? Or maybe from a
> content/plugin process starting?

That's quite possible, yes.

If you saw it months ago, it could have been bug 1395187 that caused the wait cursor to be displayed for ~5s (or until you moved the mouse) whenever a new content process was created.

I saw it briefly a couple times yesterday when opening plenty of tabs (like a dozen) at once on the reference hardware, but I couldn't find consistent steps to reproduce, and can't reproduce at all today.

> I'll watch
> out for non-startup versions of this cursor and see if I can describe a
> scenario a little better. Any tips on how to do that are highly appreciated!

I just searched some more for non-startup scenarios, and I found something that is technically startup, but isn't from a user's point of view: opening the context menu of the Firefox dock tile and clicking "Open new tab/Open new window/New private window". Technically these menu items start a new Firefox process with specific command line parameters, and that new process detects that an existing Firefox instance is already running, and sends the request to the existing Firefox before quitting. These interactions do show the appstarting cursor. Clicking a link in another application (eg. an email client) to open it in the default browser is going to do the same thing.