1930753 - In RDM with touch simulation, picking a node triggers a click event in content

Status: NEW

(DevTools :: Responsive Design Mode, defect, P2)

Description

[Julien Wajsberg [:julienw]]

Attachment: clamp.html

STR:

1. Open the attachment.
2. Turn on responsive design more (ctrl shift M).
3. Open the inspector.
4. Click the element picker.
5. Click one of the link to pick it.

=> It's followed instead of being simply picked.

Comment 1

[Julian Descottes [:jdescottes]]

Need to make sure touch simulation is enabled to reproduce the bug.
Might be related to some events which are not prevented by the inspector, but need to find the bug again for that.

Comment 2

[Julian Descottes [:jdescottes]]

Thought this might be the same as Bug 1651033, but preventing pointerup/down doesn't help. Also checked that this happens on ESR, so not related to the recent changes from Bug 1913263

Comment 3

[Julian Descottes [:jdescottes]]

Also interesting to note that this only happen if you click relatively fast. If you hold the mousebutton down a bit too long, the navigation is not triggered.

I'm guessing with touch simulation enabled, the actual click might be slightly delayed and therefore gets triggered after we remove our event suppressors from the node picker?

We can reproduce without navigation involved. A simple page with a click listener will show that the clicks are registered even when using the nodepicker: https://bug1801578.bmoattachments.org/attachment.cgi?id=9305122

STRs:

• open https://bug1801578.bmoattachments.org/attachment.cgi?id=9305122
• start RDM, enable touch simulation
• pick a node anywhere one the page
  ER: click count should not increase
  AR: click count increases

Emilio, when touch simulation is enabled, do you know if there is any mechanism in place to trigger an additional (delayed?) click event? The inspector seems to correctly suppress one click event, but if we immediately remove our handlers to "cancel" events, another click seems to go through.

Comment 4

[Emilio Cobos Álvarez (:emilio)]

I don't know off the top of my head. Maybe Hiro / Botond know?

Would be good to know if this is somehow a regression?

Comment 5

[Julian Descottes [:jdescottes]]

Thanks!

Would be good to know if this is somehow a regression?

Will run mozregression, at least already impacts current ESR 128.

Edit: mozregression stopped at the following regression window: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=60b4965aa0ca5a7a60c71229600092a65df8bc1d&tochange=849b9d9a8b6f197d20a2f66addd0e3fc1e54f6d4

I checked twice and I confirm the regression range. However I could not see any change that would explain the difference when looking at the pushlog.

Comment 6

[Botond Ballo [:botond]]

(In reply to Julian Descottes [:jdescottes] from comment #3)

when touch simulation is enabled, do you know if there is any mechanism in place to trigger an additional (delayed?) click event? The inspector seems to correctly suppress one click event, but if we immediately remove our handlers to "cancel" events, another click seems to go through.

The usual mechanism for generating a click event for a touch tap (touchstart followed by touchend) does involve a potential delay. A rough outline of the mechanism:

• The touch events themselves are forwarded from the parent process to the content process as soon as they are received. They should not themselves trigger a click event.
• APZ (in the parent or GPU process) performs gesture detection to see if the touch events constitute a single tap gesture. This may involve waiting a bit to rule out the possibility that the touch tap is the first tap of a double tap gesture. This is one potential source of delay.
• APZ informs the content process of the single tap gesture. The content process synthesizes mousedown and mouseup events.
  • (Prior to Firefox 120, there was an additional source of potential delay here, where the content process would wait to synthesize the mousedown and mouseup events in some cases to ensure that the tapped element's :active state was visible for a period of time. This delay was removed in bug 1816473.)
• The mousedown and mouseup trigger a click event in the usual way (in EventStateManager, same as if you clicked an actual mouse).

If you're using an actual touchscreen device, the click event generated in this way should be the only one you get.

With touch simulation, I guess there's an additional layer of indirection where the physical events produced by the hardware are mouse events, and RDM synthesizes touch events for them (which then go through the above steps). So perhaps a first click is being generated by the original mouse events, and the second click from the above process?

Comment 7

[Julian Descottes [:jdescottes]]

Thanks for the detailed explanation. It sounds like this is what is happening here. If I delay removing the event listeners which prevent click events to go through while picking, this fixes the issue (but I don't think we should really use this as a workaround).

Note that if we are not picking nodes, but simply using RDM in touch simulation mode, only one click gets detected by the content page. Which means that the first click, detected by the node-picker, must usually be ignored by the platform.

I looked again at the pushlog and I can't see any bug which would explain the regression.

Comment 8

[Julian Descottes [:jdescottes]]

Botond, do you know where/how touch events are synthesized from RDM? I can try to investigate this further but I don't really know this part of RDM, any pointer would help, thanks!

Comment 9

[Botond Ballo [:botond]]

I believe it happens here.