1729465 - preventDefault in pointerDown prevents multiple pointers from behaving correctly

Status: NEW

(Core :: DOM: Events, defect, P2)

Description

[[e-mail]]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Firefox/91.0
Firefox for Android

Steps to reproduce:

Go here on a multi-touch device: https://cdpn.io/mariusgundersen/fullpage/xxrRoxp

Try drawing using two pointers (fingers on a touch screen) at the same time. Try it with the checkbox in the top left corner checked and unchecked. Observe the difference in behaviour.

Actual results:

When the checkbox is checked and therefore e.preventDefault() called in the pointerdown event handler, the drawing only supports one finger, not two. If e.preventDefault() is not called in the pointerdown event handler it works smoothly, and multiple pointers can draw at the same time

Expected results:

When e.preventDefault() has been called in pointerdown the pointermove events should be triggered regularly by both pointers.

Comment 1

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(sick)]

Could you take a look, Edgar?

Comment 2

[Edgar Chen [:edgar]]

I could reproduce this, will take a look.

Comment 3

[Rory Renton]

I am experiencing this problem on android with the latest Geckoview.

if preventDefault() is called on the pointerDown then any multi-touch after the first one only emits events if the first finger isn't moving.

Comment 4

[Rory Renton]

this also happens on my laptop with multi-touch support:

Linux Fedora 35, Firefox 94.0 (64-bit).

multi-touch support only works while using wayland, so only noticed recently when I set it to use that.

Comment 5

[Sebastian Müller]

Can reproduce on Android tablets and Windows 11 with current FF versions.
Preventing default on a non-primary pointer does not seem to cause the bug to happen. But in some cases you want to call preventDefault() on the primary pointer in order to avoid that some platform default mechanism will kick in. Since you do not know whether there will be a second pointer, I don't see how this bug can be worked around. It may not seem obvious that this is a critical feature for some apps. But if you want to implement a proper pinch zoom or two finger panning, then this is almost impossible on Firefox with touch devices with this bug in place.
See this demo on a touch device and compare pinch zooming with Safari/Chromium and Firefox.
https://live.yworks.com/demos/view/events/index.html
Firefox does not work at all since you mostly only get events for one touch point which is obviously not enough for a pinch-gesture. Interestingly if you rest the finger that works and move the second finger some of the events come through. However this results in even more choppy behavior.

Comment 6

[Sebastian Müller]

Shouldn't this bug be in "confirmed" status? The current assignee was able to reproduce the issue and others confirmed it and there is a nice repro available, too.

Comment 7

[michael.baur]

I am a colleague of Sebastian Müller. We will soon replace the app at the URL above with an updated version that includes a Firefox-specific workaround so that the problem doesn't show up anymore. Our browser detection simply checks if "Firefox" is included in the user agent, so you can easily work around it to continue seeing the issue.

Comment 8

[rachelk]

(In reply to michael.baur from comment #7)

I am a colleague of Sebastian Müller. We will soon replace the app at the URL above with an updated version that includes a Firefox-specific workaround so that the problem doesn't show up anymore. Our browser detection simply checks if "Firefox" is included in the user agent, so you can easily work around it to continue seeing the issue.

I was curious what the Firefox-specific workaround you came up with was! Currently dealing with the same issue and our current workaround involves using TouchEvents vs PointerEvents , but it makes things significantly more complicated.

Comment 9

[Sebastian Müller]

I was curious what the Firefox-specific workaround you came up with was!

In our case, simply not calling preventDefault was a feasible workaround in that situation. It depends on whether this semantic change also works for you. I'd rather see this fixed, properly, of course, instead.

Comment 10

[BugBot [:suhaib / :marco/ :calixte]]

Clear a needinfo that is pending on an inactive user.

Inactive users most likely will not respond; if the missing information is essential and cannot be collected another way, the bug maybe should be closed as INCOMPLETE.

For more information, please visit BugBot documentation.

Comment 11

[mail]

We (or rather Sebastian) replied, but we were not aware that this was not enough to delete the needinfo status.

Comment 12

[[e-mail]]

This bug is still present in the latest beta version of Firefox for Android. The link in the original issue doesn't seem to work correctly anymore, this one should work still https://codepen.io/mariusgundersen/pen/xxrRoxp