1546022 - Cursor sometimes not changing to the pointer cursor when hovering links

Status: VERIFIED FIXED

(Core :: DOM: Navigation, defect, P2)

Description

[Itiel]

This is a regression from bug 1542415.

STR:

1. Latest Nightly, Windows 10
2. Open a new tab
3. Open bug 1542415 and wait for the page to finish loading. Don't move your mouse around (preferably at all)
4. Hit End in the keyboard
5. Without moving the cursor over any text or other links, hover the "fixed" link in comment 12

AR:
Normal cursor

ER:
Pointer cursor

There may be a much easier STR to follow; this is STR the worked for me consistently to verify this is a regression from bug 1542415.

Comment 1

[Kyle Machulis [:qdot] [:kmachulis] (INACTIVE)]

Taking this, though I'm pretty sure this probably falls out of whatever is also causing bug 1546019. Gonna work on that one first (mostly because I've already ni?'d other teams on it) and see if it fixes this, then will dupe this one if that's the case.

Comment 2

[Jonathan Watt [:jwatt]]

The patch for bug 1546019 just landed, so you could retest now.

Comment 3

[Kyle Machulis [:qdot] [:kmachulis] (INACTIVE)]

This seems fixed to me now after bug 1546019 landed, so calling it a duplicate of bug 1546019.

Comment 4

[Itiel]

(In reply to Kyle Machulis [:qdot] [:kmachulis] from comment #3)

This seems fixed to me now after bug 1546019 landed, so calling it a duplicate of bug 1546019.

I can still reproduce on latest Nightly :(

Comment 5

[Kyle Machulis [:qdot] [:kmachulis] (INACTIVE)]

I can't repro in 2019-05-01 Nightly, on linux or windows.

Comment 6

[Itiel]

(In reply to Kyle Machulis [:qdot] [:kmachulis] from comment #5)

I can't repro in 2019-05-01 Nightly, on linux or windows.

New and more precise STR:

1. Latest Nightly, Windows 10
2. Copy this link: https://bugzilla.mozilla.org/show_bug.cgi?id=1542415
3. Open a new tab
4. Make sure the URL bar is focused
5. Move your mouse to the content area in a place where in the next step the mouse won't hover any text, links or images. Don't move your mouse until step 7
6. Ctrl-V, Enter, wait for the page to load fully
7. Carefully move your mouse to the "Kyle Machulis [:qdot] [:kmachulis]" link under the People section in the Reporter entry without hovering over any texts or images

Another STR:

1. Latest Nightly, Windows 10
2. Copy this link: https://bugzilla.mozilla.org/show_bug.cgi?id=1542415
3. Open a new tab
4. Make sure the URL bar is focused
5. Hover over any tile in the New Tab. Don't move your mouse from that spot
6. Ctrl-V, Enter, wait for the page to load fully -- see now that the cursor is stuck on the pointer one, never mind what you hover. Switching to another tab/window and back fixes this.

Comment 7

[Ciprian Muresan [:cmuresan], Ecosystem QA]

[Tracking Requested - why for this release]:
The mouse cursor remains stuck with a specific pointer (hand, caret or arrow) regardless of what elements are hovered. Recent regression.

I am also able to reproduce this issue on the latest Nightly 68.0a1 (Build ID 20190502220333) on Windows 10 x64, macOS 10.14, and Arch Linux 4.14.3.

STR:

1. Start the Browser with a clean new profile.
2. Click the Facebook Top Site.
3. Move the mouse around and observe the cursor.

Screen recording Link

Comment 8

[Neha Kochar [:neha]]

Matt, are you the right person to look into this? If not, can you suggest someone?

Comment 9

[Kyle Machulis [:qdot] [:kmachulis] (INACTIVE)]

I got the STR in Comment 7 to work, via a clean profile.

Comment 10

[Matt Woodrow (:mattwoodrow)]

It looks like this is assigned to Kyle for now.

Comment 11

[Kyle Machulis [:qdot] [:kmachulis] (INACTIVE)]

I'm leaving the company next week, and will most likely not have a chance to look at this.

Comment 13

[Matt Woodrow (:mattwoodrow)]

Looks like this is a DOM regression, so reassigning ni? to nika.

Comment 14

[Nika Layzell [:nika] (ni? for response)]

It looks like we're probably going to unfortunately back this out again and work to re-land it when these issues are fixed. Unfortunately, I don't have cycles to work on this at this instant, so it might end up not being landed for a short while.

Comment 15

[Julien Cristau [:jcristau]]

The pref change was backed out in bug 1551993.

Comment 16

[Neha Kochar [:neha]]

Nika, you were also experiencing this. Can you confirm if this is a layout issue?

Comment 17

[Nika Layzell [:nika] (ni? for response)]

It might be, I'm not sure. I don't fully understand the mechanism which changes the cursor hover.

I think we set the cursor right now here: https://searchfox.org/mozilla-central/rev/7e158713cf5a8514fa8161dd4a239737b05da64d/dom/ipc/BrowserParent.cpp#1916

I'm guessing we're not setting something up correctly so we're not calling it when we otherwise would? It would be nice to have someone look into this logic and help figure out why it's not being set up correctly, either from layout or otherwise.

Comment 18

[Neha Kochar [:neha]]

Matt, could you please look into this?

Comment 19

[Matt Woodrow (:mattwoodrow)]

I can't reproduce this (with the pref turned back on). Does this still show up for anyone?

Comment 20

[Itiel]

I can still reproduce the second STR from comment 6 with the pref on.

Comment 21

[Matt Woodrow (:mattwoodrow)]

It looks like we ignore requests from a tab to set the cursor unless BrowserParent::mTabSetsCursor is true. We also set that to true by generating a mouse enter event when we first move the mouse into a remote frame.

If we start with the mouse over an in-process tab (like about:home), with a custom cursor set, and then navigate to a URI that will be remote (like bugzilla), then the newly created BrowserParent will have mTabSetsCursor=false.

The tab sends requests to change the cursor, but we ignore them, until we get a new mouse enter event (moving the mouse out of the tab and back again fixes the issue).

Smaug, any ideas on the best way to fix this?

Comment 22

[Olli Pettay [:smaug][[e-mail]]]

about:home isn't in-process.

But I can see that there could be issue if we don't send eMouseEnterIntoWidget after somehow switching BrowserParent.
Could we do something like https://searchfox.org/mozilla-central/rev/34cb8d0a2a324043bcfc2c56f37b31abe7fb23a8/dom/ipc/BrowserParent.cpp#1340-1354 when doing process switch, and also ensure then that mTabSetsCursor is set to true?

Comment 23

[Matt Woodrow (:mattwoodrow)]

Attachment: Bug 1546022 - Activate mouse over state for new BrowserParents. r?smaug

Comment 24

[(No longer employed by Mozilla) Aaron Klotz]

This got significantly worse sometime between Sep 8 and Sep 10. I have had a hard time tracking this down since it does not consistently reproduce.

Comment 25

[Shane Hughes [:aminomancer]]

It seems pretty consistent for me. Every time I open a new tab, if I keep my mouse inside the browser box, the cursor never changes, even if I click a link and subsequently load its page in the same tab. Then, I can consistently change the cursor on hover if I move the cursor out of the browser box or ctrl+tab to another tab then back. I haven't noticed any inconsistent behavior about it personally

Comment 26

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/3a49482c8210
Activate mouse over state for new BrowserParents. r=smaug

Comment 27

[Oana Pop-Rus]

Backed out for for build bustages in nsFrameLoaderOwner.cpp

Push with failure: https://treeherder.mozilla.org/#/jobs?repo=autoland&resultStatus=superseded%2Ctestfailed%2Cbusted%2Cexception%2Crunnable&revision=3a49482c8210ad3afc7c86f6f497a4d09115b406&selectedJob=267161949

Failure log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=267161949&repo=autoland&lineNumber=25010

Backout: https://hg.mozilla.org/integration/autoland/rev/d3f4115964cc3920bc29f1287ce22a5da298e8ae

Comment 28

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/24535654898a
Activate mouse over state for new BrowserParents. r=smaug

Comment 29

[Noemi Erli[:noemi_erli]]

https://hg.mozilla.org/mozilla-central/rev/24535654898a

Comment 30

[Vlad Lucaci, Thunderbird QA (:vlucaci)]

Hello,

Managed to reproduce this issue with the STR from comment 7 with 68.0a1 (2019-05-03 buildID:20190503215639) on Windows 10x64.

Confirming this issue as verified fixed on 72.0a1(buildID:20191028215046) and 71.0b5(buildID:20191028110005) with Windows 10x64, macOS10.14.6 and Ubuntu 18.04.