1695574 - pointermove fails to fire on a touch screen

Status: RESOLVED FIXED

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

Description

[ian]

Attachment: broke.html

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0 Safari/605.1.15
Firefox for Android

Steps to reproduce:

In Firefox 77+, on a touch screen device or on desktop simulating touches:
Inside of a pointerdown handler, add a pointermove handler to the document. Also, in the the pointerdown handler, reappended the event target to its parent.

Note: Though this reappending is kinda weird, it's necessary when managing z-space in SVGs.

Actual results:

The pointermove handler is never called during subsequent pointermove / drag.

Expected results:

The pointermove handler should be called.
(Works in iOS and Chrome)

Comment 1

[ian]

May be related to https://bugzilla.mozilla.org/show_bug.cgi?id=1609529

Comment 2

[Andrei Bodea[:andrei]]

Thank you for this report!
Can you please add the steps on how to reproduce this issue?
Also, can you confirm that you can reproduce it on a physical Android device? (attach a video if possible).

Note that I clicked on it and then I tried to drag it down, but on Fenix, we have drag down to refresh on a page.

Comment 3

[ian]

I'll try and provide a video later today.

Note: In the example, there's no need to drag down specifically. You can touch the button and move your finger up or sideways for example.

Comment 4

[Andrei Bodea[:andrei]]

Hello Ian, can you please attach the video when you have time?
Thanks!

Comment 5

[ian]

Attachment: Issue on Samsung Galaxy Tab A SM-T290 (2019)

Comment 6

[ian]

Attachment: Test-case on desktop with and without Responsive Design Mode enabled

Comment 7

[ian]

Sincere apologies!

I've added two videos. FWIW, the issue also reproduces on desktop with Responsive Design Mode enabled.

Comment 8

[Mirko Brodesser (:mbrodesser-Igalia)]

Edgar: can you please help triaging this ticket?

Comment 9

[Edgar Chen [:edgar]]

Yeah, looks like something related to bug 1609529. But a bit different, in this case, the element is re-appended to the DOM tree.
I will take a closer look at some point.

Comment 10

[Olli Pettay [:smaug][[e-mail]]]

Could we try to prioritize this a bit?

Comment 11

[Jason Orendorff]

I just hit the same issue:

• I'm trying to implement a "drag"-type interaction, initiated by a pointerdown event
• I'm moving the target element around in the DOM before doing setPointerCapture
• pointermove events are not delivered, even though setPointerCapture succeeds.
• Issue only happens on Firefox mobile, alas.

My test case is not nearly as minimal, but it contains a strange clue: it implements a very similar interaction that does not trigger the bug. Details in the attachment.

Comment 12

[Jason Orendorff]

Attachment: 200-line test case

Comment 13

[Jason Orendorff]

• Issue only happens on Firefox mobile, alas.

...Or on desktop with touch simulation enabled, like the original reporter. Not just the mobile product.

Comment 14

[Jason Orendorff]

Moving or removing the original pointerdown target element seems necessary.

With this patch, the bug doesn't happen.

diff --git a/simpler.html b/simpler.html
index 0b0c85e..9f22828 100644
--- a/simpler.html
+++ b/simpler.html
@@ -88,7 +88,8 @@
 
       function movePieceToDragGroup(dragGroup, i) {
         const piece = document.getElementById("piece-" + i);
-        dragGroup.appendChild(piece);
+        dragGroup.innerHTML += piece.outerHTML.replace('id="piece-', 'id="fake-dragging-piece-');
+        piece.style.visibility = "hidden";
       }
 
       function onDragMove(event) {
@@ -110,6 +111,7 @@
           }
           for (const i of pieceIds) {
             const piece = document.getElementById("piece-" + i);
+            piece.style.visibility = null;
             document.getElementById("board").appendChild(piece);
           }
           const e = document.getElementById("drag-group");

Comment 15

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

(In reply to Olli Pettay [:smaug][[e-mail]] from comment #10)

Could we try to prioritize this a bit?

Sure! Will plan for it.

Comment 16

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(away: 6/25-6/28)]

Odd, this is not reproducible if [the testcase is in an <iframe> with the touch simulator. If I unwrap the test from the <iframe>, I got the following events only pointerdown on the <button> and click on the <button>.

Comment 17

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(away: 6/25-6/28)]

Hmm, and I disable e10s to get the dispatcher of eTouchStart and eTouchMove, I cannot reproduce this bug...

Comment 18

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(away: 6/25-6/28)]

Oh, it seems that this is caused by this if condition. Indeed, it's not defined by the specs. The code was introduced at initial implementation of Pointer Events. And I don't find the comments for this check in the bug. Therefore, I guess that nobody knows about the reason why we considered as so.

Comment 19

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(away: 6/25-6/28)]

Oh, no! Chrome's behavior is also really odd, we probably cannot follow it as-is.

Chrome dispatches pointerup immediately after pointerdown. Then, appending the target cause another pointerdown! Then, touchstart is fired which is not followed by touchmove events. Finally, pointerup and touchend are fired. I don't understand why pointerdown is retriggered...

Comment 20

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(away: 6/25-6/28)]

Additionally, Chrome starts dispatching touchmove once the touch moves out from the target...

Comment 21

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(away: 6/25-6/28)]

(In reply to Masayuki Nakano [:masayuki] (he/him)(JST, +0900) from comment #19)

Oh, no! Chrome's behavior is also really odd, we probably cannot follow it as-is.

Chrome dispatches pointerup immediately after pointerdown. Then, appending the target cause another pointerdown! Then, touchstart is fired which is not followed by touchmove events. Finally, pointerup and touchend are fired. I don't understand why pointerdown is retriggered...

Ah, this is caused by a bug of my test. The extra pointerdown and pointerup are not fired actually. However, the touchmove issue is odd.

Comment 22

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(away: 6/25-6/28)]

Attachment: Bug 1695574 - Make `PresShell::EventHandler::HandleEventUsingCoordinates` keep handling touch events after preceding pointer event target is removed r=smaug!,edgar!,#dom-core

As far as investigating the behavior of the other browsers, touch events are
dispatched the same target as the preceding pointerdown even after the target
is removed from the DOM tree. However, the following pointer events are
dispatched on the target as usual (i.e., the element under the pointer except
when the pointer is captured). However, our code stops handling touch events
if the preceding pointerdown removes the target and not dispatching
touchstart causes not dispatching the following touch events so that no
click event is fired.

This patch makes the touch event dispatching path work without frame and
keep handling even with an orphan event target.

Depends on D202377

Comment 24

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/0c3a2df68be4
Make `PresShell::EventHandler::HandleEventUsingCoordinates` keep handling touch events after preceding pointer event target is removed r=smaug,edgar,dom-core

Comment 25

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/45049 for changes under testing/web-platform/tests

Comment 26

[Serban Stanca [:SerbanS]]

https://hg.mozilla.org/mozilla-central/rev/0c3a2df68be4

Comment 27

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR merged by moz-wptsync-bot