Closed Bug 1447297 Opened 2 years ago Closed 2 years ago

Avoid showing the wait cursor on the first browser window

Categories

(Core :: Widget: Win32, enhancement)

All
Windows
enhancement
Not set

Tracking

()

RESOLVED FIXED
mozilla61
Tracking Status
firefox61 --- fixed

People

(Reporter: florian, Assigned: florian)

References

(Blocks 1 open bug)

Details

(Whiteboard: [fxperf:p1])

Attachments

(1 file)

During startup, when the first window is shown, the dock icon starts appearing and the cursor changes to the "wait" cursor (no arrow, just the animated circular indicator).

The "wait" cursor disappears a little while later once we are mostly done showing the browser UI.

When setting browser.startup.blankWindow (from bug 1336227) to true, the wait cursor remains until the user moves the mouse, and this blocks pref'ing it on for Nightly.
I spent some time investigating this. The cursor is set while processing mouse events. During a normal startup, we typically set the cursor 5-7 times. It's first done twice (one of these two updates disappears if I turn dom.w3c_pointer_events.enabled off), and then a couple more times on the refresh driver ticks, from nsSynthMouseMoveEvent::WillRefresh.
I saw this by putting a sleep() in EventStateManager::UpdateCursor and then profiling startup. For the normal case, I get https://perfht.ml/2u5hnIa The first update happens about at the time of the PAPZInputBridge::Msg_ReceiveMouseInputEvent marker.

If I profile startup with browser.startup.blankWindow set to true, EventStateManager::UpdateCursor is not called (until I actually move the mouse). In the profile (https://perfht.ml/2u1JMPf), the PAPZInputBridge::Msg_ReceiveMouseInputEvent marker is placed way after we first paint the blank window, but before we start loading browser.xul.

(I initially thought PAPZInputBridge::Msg_ReceiveMouseInputEvent was what triggered the mouse event we handle, but it's actually not the case; if I disable the GPU process in about:config, I no longer have this marker in the profiles, but the cursor behavior is unchanged.)


Windows sends us a WM_SETCURSOR message when it wants us to set the cursor. We receive this message about 3 times during startup, but currently don't do anything with it. I tried setting the cursor from it. That solves my problem of the wait cursor remaining there forever when browser.startup.blankWindow is true, but the wait cursor is still shown a little bit (a profile shows that the first WM_SETCURSOR message is received about 160ms after we are done with first paint on my Dell XPS 13").

This made me suspect that the problem may just be that we are not setting a default cursor when showing new windows. I tried to set the cursor in nsWindow::Show right before we call ::ShowWindow. This gives me a trivially simple patch, that works well in my local testing. For both values of browser.startup.blankWindow, I don't see the wait cursor anymore during startup.
Attached patch PatchSplinter Review
Attachment #8960590 - Flags: review?(jmathies)
Comment on attachment 8960590 [details] [diff] [review]
Patch

lstm
Attachment #8960590 - Flags: review?(jmathies) → review+
Blocks: 1447719
Pushed by florian@queze.net:
https://hg.mozilla.org/integration/mozilla-inbound/rev/57d72a8be274
Set the cursor right before showing new windows to avoid showing the wait cursor during startup, r=jimm.
https://hg.mozilla.org/mozilla-central/rev/57d72a8be274
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla61
You need to log in before you can comment on or make changes to this bug.