User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:56.0) Gecko/20100101 Firefox/56.0 Build ID: 20170722072631 Steps to reproduce: Since this morning's Nighly update, 56.0a1 (2017-07-22) (64-bit) (buildID 20170722072631) running under Windows 7 Home Premium SP1 (64-bit), on Reddit, in the Firefox subreddit, when I click on "comments" for a post, the mouse pointer is a hand to indicate a link, but when a new tab opens and focus is moved to it, the mouse pointer remains a hand instead of changing to the more typical arrow. To reproduce: Create a brand new profile, close Firefox Nightly, then launch Firefox Nightly using that new profile. Log on to Reddit, and in profiles (wrench), change the top option, "Clicking options", to select [x] "open links in a new window". Go to https://www.reddit.com/r/firefox/ In the lists of posts, for any of the posts, move the mouse pointer to the "comment" link. The mouse pointer will change to a hand. Click on the "comment" link. This will open a new tab (thanks to the preference above), the focus will be that new tab. Actual results: After the new tab finishes loading, the mouse pointer will remain a hand, and will stay a hand no matter where within the tab window one moves the mouse (even clicking in a text input field will leave the mouse pointer shaped like a hand). Only after the mouse pointer has been moved out of the tab (I moved it over to exposed Desktop and back), will the mouse pointer start behaving correctly on that new tab (being a hand over a link, a pointer in other areas). Expected results: Up through yesterday, the mouse pointer would change to an arrow once the tab is loaded, and the shape would automatically change as per context (such as a hand when hovering over a link). Note: this is solidly reproducible at https://www.reddit.com/r/firefox/ Note: I never noticed any such behavior before today's update, but it is solid since this morning's update. It doesn't appear to occur on a Google search. It doesn't appear to occur on Reddit if one isn't logged in (which, by the way, implies that the "clicking options" opens links in the _same_ window). I did run a regression and appears to point to: 2017-07-22T17:55:46: DEBUG : Found commit message: Bug 1351148 Part8: Revise browser_1008559_anchor_undo_restore.js to continue the test after processing the mouse event. r=smaug. MozReview-Commit-ID: BYF94RsKhR6 The regression was run using the above-mentioned profile as the profile to clone (which would have the logon cookies for Reddit since I did the above steps before running the regression), date range of 2017-07-20 through 2017-07-22, and on each test I simply went to https://www.reddit.com/r/firefox/ then clicked on a "comment" link for any of the posts listed, and noted if the tab that came up had the mouse pointer a hand and stayed a hand when I moved it across links and text input fields. I have attached the Log and the Bisection Informations.

:stone, This seems to be regression due to Bug 1351148. Could you look this?

Second Failure Example, again with Firefox Nightly 56.0a1 (2017-07-22) (64-bit): Using either a new profile or my usual profile for Nightly, Click on Menu icon -> Add-ons. Click on the "Appearance" side tab. Then click on "Choose from thousands of themes". Actual results: When the mouse moves over the link, "Choose from thousands of themes", it will change to a hand. Clicking on the link will open a new tab and on that tab display a bunch of possible themes, but THE MOUSE POINTER WILL REMAIN A HAND. Expected results: Once that page is displayed, I would expect the mouse pointer to change back to an arrow, except when moved over a graphic representation of a theme (which is clickable) or over a clickable link, where I would expect it to change into a hand. Again, once the mouse pointer is moved off of Firefox (moved to an exposed part of the desktop) and moved back, it behaves like I would expect it to behave. The expected results are seen in Firefox 54.0.1 (64-bit).

Tried regression on Appearance -> "Choose from thousands of themes", not specifying any profile (so a new profile is created for each test). I learned that the problem apparently isn't there when there are two tabs and then one goes into menu -> Add-ons -> Appearance and then clicks on "Choose from thousands of themes". However, if running the regression one closes the first tab (Welcome to Nightly) so only one tab is left (Mozilla Privacy notice), then goes into Menu -> Add-ons -> Appearance, the "Choose from thousands of themes" cursor hand bug is there and again: when it is present, the hand remains a hand when presented with a screen of different themes, rather than changing to an arrow except when hovering over a clickable link. Again, the regression log ends with: 2017-07-22T23:56:40: DEBUG : Found commit message: Bug 1351148 Part8: Revise browser_1008559_anchor_undo_restore.js to continue the test after processing the mouse event. r=smaug. MozReview-Commit-ID: BYF94RsKhR6 2017-07-22T23:56:40: INFO : The bisection is done. 2017-07-22T23:56:40: INFO : Stopped I am uploading these logs as regression-themes*.txt

And also on Nightly56.0a1 Windows10 x64, busy cursor would not dismiss...

Possible that Bug 1383430 is related? It wouldn't surprise me if fixing this bug also fixes 1383430.

Pushed by sshih@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/15b71aceffb4 Resend a MouseEnterIntoWidget event to TabChild when it's ready to handle input events. r=smaug.

Confirmed fixed as per my two test cases (original description and comment 4). Thank you!

Backout by cbook@mozilla.com: https://hg.mozilla.org/mozilla-central/rev/fd5cc34890a5 Backed out changeset 15b71aceffb4

backed out on request from stone

So is this bug now fixed after the backout of bug 1351148?

The bug is fixed. I don't know if specifically for backing out 1351148, but it has been fixed for a few days now.

(In reply to Mark from comment #18) > The bug is fixed. I don't know if specifically for backing out 1351148, but > it has been fixed for a few days now. This is a regression of bug 1351148. I had landed a patch to fix it but been backout when doing clean backout of bug 1351148. So it shouldn't be reproducible now. I'll land the patch with the patches of bug 1351148 once ready.

The bug was gone when running Firefox nightly yesterday. The bug is still gone running Firefox nightly today. Yesterday Firefox nightly was release 56. This morning's update was to release 57. In both cases, the problem has disappeared. FF tracking flags do not yet mention FF57.

Moving 56-status to unaffected as bug 1351148 was backed-out from 56.

I think this is resolved after relanding the patches of bug 1351148. Verified on nightly with pref'ed on and can't reproduce it.