Mouse pointer wrong shape when link opens new tab

RESOLVED WORKSFORME

Status

()

Core
DOM: Events
RESOLVED WORKSFORME
10 months ago
9 months ago

People

(Reporter: Mark, Assigned: stone)

Tracking

({regression})

56 Branch
mozilla56
regression
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox-esr52 unaffected, firefox54 unaffected, firefox55 unaffected, firefox56 unaffected)

Details

Attachments

(6 attachments)

(Reporter)

Description

10 months ago
Created attachment 8889108 [details]
Regression_2_bisection_informations.txt

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.
(Reporter)

Comment 1

10 months ago
Created attachment 8889109 [details]
Regression_2_log.txt

Comment 2

10 months ago
:stone,
This seems to be regression due to Bug 1351148.
Could you look this?
Blocks: 1351148
Flags: needinfo?(sshih)
Keywords: regression
(Reporter)

Comment 3

10 months ago
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).

Updated

10 months ago
Status: UNCONFIRMED → NEW
Ever confirmed: true

Updated

10 months ago
status-firefox54: --- → unaffected
status-firefox55: --- → unaffected
status-firefox56: --- → affected
status-firefox-esr52: --- → unaffected
(Reporter)

Comment 4

10 months ago
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
(Reporter)

Comment 5

10 months ago
Created attachment 8889136 [details]
Regression_themes_1_bisection_informations.txt
(Reporter)

Comment 6

10 months ago
Created attachment 8889137 [details]
Regression_themes_1_log.txt

Comment 7

10 months ago
Created attachment 8889235 [details]
screencast

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

Comment 8

10 months ago
Possible that Bug 1383430 is related? It wouldn't surprise me if fixing this bug also fixes 1383430.
(Assignee)

Updated

10 months ago
Assignee: nobody → sshih
Flags: needinfo?(sshih)
(Assignee)

Comment 10

10 months ago
Created attachment 8889696 [details] [diff] [review]
Bug 1383485: Resend a MouseEnterIntoWidget event to TabChild when it's ready to handle input events.
(Assignee)

Updated

10 months ago
Attachment #8889696 - Flags: review?(bugs)

Updated

10 months ago
Attachment #8889696 - Flags: review?(bugs) → review+

Comment 12

10 months ago
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.

Comment 13

10 months ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/15b71aceffb4
Status: ASSIGNED → RESOLVED
Last Resolved: 10 months ago
status-firefox56: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla56
(Reporter)

Comment 14

10 months ago
Confirmed fixed as per my two test cases (original description and comment 4).

Thank you!

Comment 15

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

Comment 16

10 months ago
backed out on request from stone
Status: RESOLVED → REOPENED
status-firefox56: fixed → ---
Flags: needinfo?(sshih)
Resolution: FIXED → ---
Has Regression Range: --- → yes
Has STR: --- → yes
status-firefox56: --- → affected
So is this bug now fixed after the backout of bug 1351148?
Flags: needinfo?(Mark12547)
(Reporter)

Comment 18

10 months ago
The bug is fixed. I don't know if specifically for backing out 1351148, but it has been fixed for a few days now.
Flags: needinfo?(Mark12547)
Depends on: 1386791
(Assignee)

Comment 19

10 months ago
(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.
Flags: needinfo?(sshih)

Comment 20

10 months ago
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.

Comment 21

10 months ago
Moving 56-status to unaffected as bug 1351148 was backed-out from 56.
status-firefox56: affected → unaffected
(Assignee)

Updated

9 months ago
Blocks: 1390044
(Assignee)

Comment 22

9 months ago
I think this is resolved after relanding the patches of bug 1351148. Verified on nightly with pref'ed on and can't reproduce it.
Status: REOPENED → RESOLVED
Last Resolved: 10 months ago9 months ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.