Closed
Bug 1447297
Opened 7 years ago
Closed 7 years ago
Avoid showing the wait cursor on the first browser window
Categories
(Core :: Widget: Win32, enhancement)
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)
|
1.15 KB,
patch
|
jimm
:
review+
|
Details | Diff | Splinter Review |
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.
| Assignee | ||
Comment 1•7 years ago
|
||
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.
| Assignee | ||
Comment 2•7 years ago
|
||
Attachment #8960590 -
Flags: review?(jmathies)
Comment 3•7 years ago
|
||
Comment on attachment 8960590 [details] [diff] [review]
Patch
lstm
Attachment #8960590 -
Flags: review?(jmathies) → review+
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.
Comment 5•7 years ago
|
||
| bugherder | ||
Status: NEW → RESOLVED
Closed: 7 years ago
status-firefox61:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla61
You need to log in
before you can comment on or make changes to this bug.
Description
•