1466009 - Changing tab with left button pressed sticks cursor icon

Status: RESOLVED WORKSFORME

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

Description

[mark]

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

Steps to reproduce:

1) On windows, press and hold the left button over a link. The cursor should be the hand-pointer icon due to being over a link.

2) Without releasing left button, change the active tab using Ctrl+1 or similar.

This might seem a little contrived, but it is an issue for gestures extensions that support Chord gestures such as Foxy Gestures. Changing the active tab using tabs.update() has the same sticky cursor icon issue.


Actual results:

The cursor is stuck in the hand-pointer icon in the newly activated tab.


Expected results:

Cursor icon should be reset to whatever the proper icon is for the newly activated tab.

Comment 1

[laszlo.bialis]

Hi,

I've managed to reproduce the issue above using the latest Nightly 62.0a1 Build ID:20180605220158 on Win10 x64. 

Please also see Bug 252249, maybe it's a duplicate of it.

Comment 2

[Andrew Overholt [:overholt]]

Gijs, sorry to bug you, but do you know what code controls the cursor type?

Comment 3

[:Gijs (he/him)]

(In reply to Andrew Overholt [:overholt] from comment #2)
> Gijs, sorry to bug you, but do you know what code controls the cursor type?

AFAICT from a quick check, I see two avenues: pointer lock code goes through the DOM event state manager and calls SetCursor on the widget layer, which for e10s forwards through TabParent/TabChild IPC messages to the toplevel widget, if need be. The second avenue is that layout propagates cursor styles from individual frames. Looking for blame at https://searchfox.org/mozilla-central/rev/6f86cc3479f80ace97f62634e2c82a483d1ede40/layout/generic/nsFrame.cpp#5201 , maybe :xidorn or :masayuki can help. In principle, I would expect the layout/dom code to get enough information here to be able to send a cursor update to Windows, but I'm probably missing something.

Comment 4

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(away 4/27 - 5/6)]

I'm not so familiar with pointing device event handling though, looks like that it's related to capture of mouse events.

Perhaps, somebody started to capture mouse events at mouse down, then, tab switching didn't cause releasing the capture, so, perhaps, PresShell do something in mouse capture mode. I don't know why after a mousemove, I cannot switch active tab with keyboard. But perhaps, before the first mousemove, keyboard operation should not cause switching tabs.

Comment 5

[Xidorn Quan [:xidorn] UTC+11]

I'm not familiar with event dispatching. Experimenting a bit, it seems to be an e10s-specific issue, while it's unrelated to platform.

I think the reason is that, eMouseEnterIntoWidget is sent to the wrong TabParent somehow. I put printf into TabParent::SendRealMouseEvent[1] and found that when button is pressed, both eMouseExitFromWidget and eMouseEnterIntoWidget would be dispatched to the previous TabParent, and thus the new tab doesn't have mTabSetsCursor and consequently cannot update cursor.

I guess eMouseEnterIntoWidget is generated in EventStateManager::DispatchMouseOrPointerEvent[2] so it feels like that the MouseOver event is being dispatched to a wrong element.

Someone familiar with mouse event dispatching should probably continue from here and see why MouseOver is dispatched to a wrong element in that case.


[1] https://searchfox.org/mozilla-central/rev/6f86cc3479f80ace97f62634e2c82a483d1ede40/dom/ipc/TabParent.cpp#1100-1110
[2] https://searchfox.org/mozilla-central/rev/6f86cc3479f80ace97f62634e2c82a483d1ede40/dom/events/EventStateManager.cpp#4271-4291

Comment 6

[Andrew Overholt [:overholt]]

OK, let's wait until Olli is back. Thank you all for looking into this!

Comment 7

[Edgar Chen [:edgar]]

Hi mark, recently there are some improvements for mouse cursor updating, are you still seeing this on recent Nightly?

Comment 8

[Hsin-Yi Tsai (she/her) [:hsinyi]]

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

Hi mark, recently there are some improvements for mouse cursor updating, are you still seeing this on recent Nightly?

FWIW, I don't see this issue on nightly 80.

Comment 9

[mark]

I tested both 78 and 80 and am no longer able to reproduce the issue.

Comment 10

[Edgar Chen [:edgar]]

Thanks for verifying, close as WORKSFORME.