Closed Bug 1638091 Opened 5 years ago Closed 5 years ago

Mouse cursor sometimes stuck in arrow mode

Categories

(Core :: DOM: UI Events & Focus Handling, defect)

Product:
Core
Component:
DOM: UI Events & Focus Handling
Version:
78 Branch
Type:
defect

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1635784

People

(Reporter: gwarser, Assigned: edgar)

Details

Attachments

(1 file, 1 obsolete file)

Cursor stuck.mp4
1.36 MB, video/mp4
Details

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0

Steps to reproduce:

Started noticing yesterday that cursor sometimes stops changing to "hand" over links.

Best STR I can find is:

  • use Manjaro KDE with mouse gestures enabled (down-right for Ctrl+W / close tab)
  • in Firefox enable autoscrolling, disable smooth scrolling
  • search for some thing on Bugzilla, for ex. https://bugzilla.mozilla.org/buglist.cgi?quicksearch=ALL%20cursor&list_id=15248077 (also happens on old Reddit)
  • open ~10 tabs by middle clicking on bugs
  • maybe scroll a bit using autoscroll
  • close tabs by down-right gesture (binded to right mouse button)
  • it's better to end gesture in right margin

Seems to also happen on Win 10, not related to mouse gestures: https://www.reddit.com/r/firefox/comments/ggltrf/weekly_nightly_discussion_for_20200509_20200515/fqi1nfl/

Actual results:

Arrow cursor does not change when hovering various elements/links on web page.

Cursor "unlocks" after moving over browser interface (tabs or context menu) or outside browser window.

Tried reproducing on Windows 10 but no luck.

Mirko, could you try on Linux?

Flags: needinfo?(mbrodesser)
Severity: -- → S3

I tried reproducing on Mac but didn't hit this bug.

(In reply to Edgar Chen [:edgar] from comment #2)

I tried reproducing on Mac but didn't hit this bug.

Ah, I think I found a way to reproduce this bug,

  • Press and hold a mouse button.
  • Close tab via keyboard shortcut (comand+w in MAC for example).

I will take a look.

Flags: needinfo?(mbrodesser)

It doesn't look like a recent regression, given that I could also reproduce the bug on 50.

Status: UNCONFIRMED → RESOLVED
Closed: 5 years ago
Resolution: --- → DUPLICATE

Reopen this bug, since bug 1619055 is no longer reproducible on the latest Nightly.

Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: DUPLICATE → ---

Still happens to me on 20200515093304. I cannot reproduce this as described in bug 1619055

An issue of mouseenter/mouseleave event is also noticeable, for example,

  1. Open multiple tabs.
  2. Load https://codepen.io/edgarchen-the-decoder/pen/ExVONrm in one of the tabs.
  3. Move the mouse to the green area.
  4. Click and hold mouse left button.
  5. Switch to another tab via keyboard shortcut (control+tab in MAC for example)
  6. Release the mouse button.
  7. Switch back to the condepen tab via clicking in tab bar.

Expected result:

Only mouseenter and mouseleave are logged in the green area.
The mouseenter is from step 3.
The mouseleave is fired because of switching to another tab in step 5.

Actual results:

Additional mouseenter is fired. And another mouseleave is fired while mousing over the web content.

While the mouse moves from the old tab to the new tab, we should dispatch a eMouseExitFromWidget to the old tab and a eMouseEnterIntoWidget to the new tab, but the eMouseEnterIntoWidget is somehow dispatched to old tab instead.

I suspect it is because we track the mouse down for dragging gesture in https://searchfox.org/mozilla-central/rev/9193635dca8cfdcb68f114306194ffc860456044/dom/events/EventStateManager.cpp#1674, and use it as mCurrentTarget in https://searchfox.org/mozilla-central/rev/9193635dca8cfdcb68f114306194ffc860456044/dom/events/EventStateManager.cpp#1827.

We probably need to overwrite mCurrentTarget for eMouseEnterIntoWidget like what we do for eMouseExitFromWidget in https://searchfox.org/mozilla-central/rev/9193635dca8cfdcb68f114306194ffc860456044/dom/events/EventStateManager.cpp#4218-4222.

Assignee: nobody → echen

I cannot be 100% sure, but:

38:11.06 INFO: Narrowed integration regression window from [78ca58d0, d1114574] (6 builds) to [25660290, d1114574] (3 builds) (~1 steps left)
38:15.50 WARNING: Skipping build ea102a496187: Unable to find build info using the taskcluster route 'gecko.v2.mozilla-central.shippable.revision.ea102a49618733aae60628d0f4304e8708274016.firefox.linux64-opt'
38:15.50 INFO: No more integration revisions, bisection finished.
38:15.50 INFO: Last good revision: 256602905ce82b1866a1d2f37b409fa768fb7ae6
38:15.50 INFO: First bad revision: d1114574b777bb00b85f73733a8bd6a78d2ad87e
38:15.50 INFO: Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=256602905ce82b1866a1d2f37b409fa768fb7ae6&tochange=d1114574b777bb00b85f73733a8bd6a78d2ad87e

bug 1625694 ?

For STR from comment 8

47:57.08 INFO: Narrowed integration regression window from [88678636, eaadf10e] (4 builds) to [e6759470, eaadf10e] (2 builds) (~1 steps left)
47:57.08 INFO: No more integration revisions, bisection finished.
47:57.08 INFO: Last good revision: e67594708db8c72ffb3720ad8ed1436a717bf502
47:57.08 INFO: First bad revision: eaadf10e4478b4480f24dadf51eb5893d2888b05
47:57.08 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=e67594708db8c72ffb3720ad8ed1436a717bf502&tochange=eaadf10e4478b4480f24dadf51eb5893d2888b05

It's bug 1607375

(In reply to gwarser from comment #13)

For STR from comment 8
It's bug 1607375

No, the symptom in comment 8 is actually a long-existing issue, I could reproduce it even in 76.
There is another symptom, bug 1638806, which is a regression of bug 1607375.
Note that the difference between the two STR is whether click and hold the mouse left button.

Let see if bug 1638806 would also fix this.

Comment on attachment 9150179 [details]
Bug 1638091 - Test reproduce the bug;

Revision D75983 was moved to bug 1639368. Setting attachment 9150179 [details] to obsolete.

Attachment #9150179 - Attachment is obsolete: true

(In reply to Edgar Chen [:edgar] from comment #14)

(In reply to gwarser from comment #13)

For STR from comment 8
It's bug 1607375

No, the symptom in comment 8 is actually a long-existing issue, I could reproduce it even in 76.
There is another symptom, bug 1638806, which is a regression of bug 1607375.
Note that the difference between the two STR is whether click and hold the mouse left button.

Ouch, sorry, right, I tested without point 4 "Click and hold mouse left button."

Probably another str for issue from comment 8

trick is to switch to the second tab when it's still loading

What happens:

mouseenter is not fired. If cursor is not moved outside green box even reloading by F5 does not fire mouseenter.

What should happen:

Good question. Chrome does not fire mouseenter immediately, but after mouse movement.

(In reply to gwarser from comment #19)

Probably another str for issue from comment 8

I think this is another issue, could you file a separate bug for it, thanks.

(In reply to Edgar Chen [:edgar] from comment #15)

Let see if bug 1638806 would also fix this.

Bug 1638806 is in the latest Nightly now.
Could you help to test if it is still reproducible on the latest Nightly?
Thanks.

Flags: needinfo?(gwarser)

(In reply to Edgar Chen [:edgar] from comment #20)

I think this is another issue, could you file a separate bug for it, thanks.

bug 1640873

Bug 1638806 is in the latest Nightly now.
Could you help to test if it is still reproducible on the latest Nightly?
Thanks.

I'm now not sure if current bug is not what I see in comment 19 (now bug 1640873).

I think I still see this issue in my current dirty profile, but I have problem reproducing with STR from comment 0 in clean profile.

It seems to still happen when page I switch to is still loading, so looks like bug 1640873. Is cursor changing and JS event firing the same code?

I will test more.

Flags: needinfo?(gwarser)
Attached video Cursor stuck.mp4 —

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Firefox/78.0
Build ID: 20200526023857

I can still reproduce the bug after bug 1638806. Yet it occurs only in my main profile (or a dupe of my main profile), not in a new profile.

Here is another STR (please refer to the attached video):

  1. In about:home, right click on a Top Site tile and click Open Link in New Window or Open Link in New Private Window. The new window should be in focus now.
  2. Immediately switch back to the original window by clicking Windows' task bar tile. Then immediately move cursor into this window's content area.
  3. Move cursor around and see if it is stuck in a particular mode.

Notes

I found 2 ways that greatly increase the rate of reproducibility:

  1. Enable Temporary Containers or ContextSearch web-ext.
  2. Make the popped out new (private) window's location appear slightly lower than that of the original window.

I can reproduce the bug around 70% of the time. It is barely, if at all, reproducible without these tricks.
Despite all that, I cannot reproduce the bug in a new profile. Perhaps other Nightly's settings are affecting it.

Workaround

  1. The bug is temporary fixed by moving the cursor out of and back into the content area until it is triggered again by whatever reason.
  2. If I go to Firefox's UI customize mode and press Done without making any changes, the bug is not reproducible (by my STR) until browser is restarted.

I also encounter this bug.
It appeared with 78.0b1 (was not there in 77b or before). I'm on Windows.
I also use Temporary Containers and ContextSearch web-ext.

(In reply to gwarser from comment #21)

Is cursor changing and JS event firing the same code?

Not the exact same code, but somehow related.
If we encounter the cursor stuck, most likely because the https://searchfox.org/mozilla-central/rev/eef39502e08bcd3c40573c65a6827828dce4a032/dom/ipc/BrowserParent.h#966 isn't updated properly.
I recently found one potential issue on it, see https://phabricator.services.mozilla.com/D80094. I suspect comment 22 is the same case.

(In reply to Fanolian from comment #22)

I can reproduce the bug around 70% of the time. It is barely, if at all, reproducible without these tricks.

The potential issue mention in comment #24 is landed. Could you help to verify if you still see this issue on the latest Nightly build (after 20200619092144)? Thanks!

Flags: needinfo?(Fanolian+BMO)

(In reply to gwarser from comment #21)

I think I still see this issue in my current dirty profile, but I have problem reproducing with STR from comment 0 in clean profile.

Could you help to verify again if you still see the issue with STR from comment #0 on the latest Nightly build (after 20200619092144)? Thanks!

Flags: needinfo?(gwarser)

(In reply to Edgar Chen [:edgar] from comment #25)

(In reply to Fanolian from comment #22)

I can reproduce the bug around 70% of the time. It is barely, if at all, reproducible without these tricks.

The potential issue mention in comment #24 is landed. Could you help to verify if you still see this issue on the latest Nightly build (after 20200619092144)? Thanks!

I tried for about 5 minutes and I still don't see the issue. I think it is fixed.
The profile now and in comment 22 do not have Fission enabled btw.

Thanks.

Flags: needinfo?(Fanolian+BMO)

(In reply to Edgar Chen [:edgar] from comment #26)

(In reply to gwarser from comment #21)

I think I still see this issue in my current dirty profile, but I have problem reproducing with STR from comment 0 in clean profile.

Could you help to verify again if you still see the issue with STR from comment #0 on the latest Nightly build (after 20200619092144)? Thanks!

I'm pretty sure this case is fixed. I even tried mozregression --find-fix. It pointed to https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=ff2a2496bb260d6a8a00e2da2d58370a6eedb194&tochange=aadf9c693336063243678cbaebec881bef1c430a only once, but three times finished in June 18.

Flags: needinfo?(gwarser)

Thanks for verifying!

Status: REOPENED → RESOLVED
Closed: 5 years ago → 5 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: