1629353 - Mouse click generated fake touch events and incorrect pointer capture events / mouse event sequence

Status: RESOLVED WORKSFORME

(GeckoView :: General, defect)

Description

[Patrick H. Lauke]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.92 Safari/537.36

Steps to reproduce:

1. pair a bluetooth mouse with Android phone (in my case, Google Pixel 2 XL)
2. go to https://patrickhlauke.github.io/touch/tests/event-listener.html
3. click the test button (which outputs all events fired, including hover events etc)

Actual results:

As part of the sequence of events from a mouse click, Firefox seems to generate "faked" touch events, and a series of events that make it look like a mish-mash of how it would handle pointer events for a touch. The series of events is roughly:

pointerdown > touchstart > (gotpointercapture) > pointerup > (lostpointercapture) > pointerout > pointerleave > touchend > pointerover > pointerenter > pointermove > mousemove > mousedown > focus > mouseup > click

Note the touchstart and touchend events, the gotpointercapture/lostpointercapture (which should not happen for mouse events, as there shouldn't be any implicit pointer capture happening https://www.w3.org/TR/pointerevents/#implicit-pointer-capture), and the fact that the sequence fires the complete set of pointer events first, then the mouse events.

Expected results:

I assume the faked touch events are a decision on the part of Firefox team to ensure that badly-coded sites (that take a naive "it's an Android/touchscreen device, so I only need to listen to touch events" approach) still work with mouse as well. However, this is in contrast now with how both iPadOS/Safari and Android/Chrome handle mouse - treating it exactly like a desktop mouse, and not trying to "fake" any touch events.

Pointer capture events should not be fired for mouse interactions (unless an explicit pointer capture happened, programmatically).

And the series of events for pointer events and mouse events should follow the more natural model from https://www.w3.org/TR/pointerevents/#mapping-for-devices-that-support-hover.

In short, something more along the lines of:

pointerdown > mousedown > focus > pointerup > mouseup > click

(I note that otherwise, mouse seems to behave more like a desktop mouse in other scenarios, which is good - it does fire pointerover/pointerenter/mouseover/mouseenter when a mouse hovers over the button, and the equivalent out/leave events when it moves away, and it fires :hover styles etc ... this seems to be a problem mostly of how actual clicks are handled)

Note also that currently Android/Chrome seems to have a bug when it comes to mouse support, where it doesn't actually do the hover stuff - see https://bugs.chromium.org/p/chromium/issues/detail?id=1028118 (just in case you want to refer to Android/Chrome as example). Currently it seems the most solid implementation of "mouse on a tablet" (and soon phone) seems to be iPadOS/Safari (but that also has bugs https://bugs.webkit.org/show_bug.cgi?id=209292)

Comment 1

[Patrick H. Lauke]

I'll add that one positive aspect as well in current Android/Firefox implementation of mouse is that (regardless of the weird event sequences etc) mouse is correctly identified in pointer events as having pointerType "mouse".

Comment 2

[Firefox Bug Husbandry Bot]

Resetting severity to default of --.

Comment 3

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

Patrick, would you mind also giving this a try on Firefox Preview (Fenix) ? And please let us know if things work better there? (It uses a more recent version of our web platform)

Comment 4

[Kartikaya Gupta (email:[e-mail])]

I'm pretty sure this is not a DOM bug. The GV layer sometimes converts mouse events to touch events depending on the TOOL_TYPE of the incoming event and the pref ui.android.mouse_as_touch. https://searchfox.org/mozilla-central/rev/7fd1c1c34923ece7ad8c822bee062dd0491d64dc/mobile/android/geckoview/src/main/java/org/mozilla/geckoview/PanZoomController.java#322,339

I don't recall the exact reasoning here but if it needs fixing the fix would go into the GV layer.

Comment 5

[Kartikaya Gupta (email:[e-mail])]

(In reply to Stefan Arentz [:st3fan] from comment #3)

Patrick, would you mind also giving this a try on Firefox Preview (Fenix) ?

But yes, the behaviour might be corrected already in Fenix, since it uses a different default value for ui.android.mouse_as_touch.

Comment 6

[Patrick H. Lauke]

Confirming that in Firefox Preview (4.3.0 / 38.0.0) the event sequence when clicking on the button is correct, with no random faked touch events.

pointerdown > mousedown > focus > pointerup > mouseup > click > pointermove > mousemove

(seems to always fire some sacrificial move events at the end, but that's not really a problem)

Comment 7

[Kartikaya Gupta (email:[e-mail])]

Great, in that case there should be nothing to do here. Fennec is no longer taking non-security patches so we can't really fix it there.

Comment 8

[Patrick H. Lauke]

so just to check: when's the new handling from Fenix making its way into Firefox's stable version?

Comment 9

[Kartikaya Gupta (email:[e-mail])]

"To be determined". It's not a great situation, I agree.

Basically the current Firefox for Android stable version (Fennec) is shipped from the ESR68 branch, which is the equivalent of the current LTS for Firefox. It's only getting security updates and high-value/low-risk patches. Fenix is the new rewrite that uses a more modular architecture and different design decisions. That's getting all the development effort and will eventually replace Fennec. It was supposed to be shipped out soonish but has been pushed back a bit. I expect it should happen within a few months but I don't know the timeline details.