1698052 - Drag and Swap Libraries are impossible to use

Status: RESOLVED DUPLICATE of bug 1481923

(Core :: Panning and Zooming, defect)

Description

[Petru-Mugurel Lingurar [:petru]]

From github: https://github.com/mozilla-mobile/fenix/issues/18451.

Info

It does for example work correctly or as expected with Monument Browser. Didn't test it with a chromium based browser, though I expect it to work there, too.

Steps to reproduce

1. Open interact.js or Draggable JS.
2. Try to drag and swap example elements.

Expected behavior

The page doesn't scroll when dragging and swapping elements.

Actual behavior

The page does scroll when trying to drag and swap elements, so it gets nearly impossible .

Device information

• Device vendor / model and Android version: Samsung Galaxy S7, Android 8.0.0
• Firefox for Android version: Nightly 210310 17:03 (Build #2015797899)

Change performed by the Move to Bugzilla add-on.

Comment 1

[Hiroyuki Ikezoe (:hiro)]

It doesn't seem to scroll for me in either link in comment 0.
Petru, can you please clarify how to reproduce this issue? Thanks!

Comment 2

[Petru-Mugurel Lingurar [:petru]]

To me it just seems that sometimes the touch intersection is not properly calculated, but I saw the same in Chrome.
Wondering if it ain't an issue with the website.
Recording of shoppify.github.io/draggable on GVE from 17 May running on a Pixel 3 - at around second 33 I think it's a clean touch that gets to scroll the page.

One difference from Chrome is that long pressing on one block will scroll the toolbar on GVE while it will select that and allow it to be placed anywhere on Chrome.

Comment 3

[Hiroyuki Ikezoe (:hiro)]

Attachment: An example to demonstrate the issue that doing preventDefault() in contextmenu event handler causes "touchcancel" event

(In reply to Petru-Mugurel Lingurar [:petru] from comment #2)

One difference from Chrome is that long pressing on one block will scroll the toolbar on GVE while it will select that and allow it to be placed anywhere on Chrome.

Thank you, Petru. This information was quite helpful to understand the difference. (that said, diagnosing the root cause took some amount of time)

So, what's going on on long pressing is we send a touchcancel event if preventDefault() was called in contextmenu event handlers. Actually the Draggable library calls preventDefault() in a contextmenu event handler. And unfortunately GeckoView also calls preventDefault() in cases where there is a link-ish element and indeed the Draggable case is one of such cases (see bug 1705672 which is a similar case that we open an unexpected context menu on long press).

The code to fire a touchcancel event when a contextmenu event handler calls preventDefault() was introduced in bug 1231570. Though I am not yet sure it's still reasonable to fire the touchcancel event, Chrome doesn't fire the touchcancel event at all.

Comment 4

[Hiroyuki Ikezoe (:hiro)]

I found the exact same issue (bug 1481923). I am going to make this as a dup of that bug.

Comment 5

[Petru-Mugurel Lingurar [:petru]]

@Hiro I would've though after fixing that the issues reported on Fenix would be fixed also but the reporter says it's still reproducing.

Comment 6

[Hiroyuki Ikezoe (:hiro)]

Petru, can you please open a new bug for the interactjs.io case? I haven't looked at the site. I just investigated the Draggable JS case. Presumably the interactjs.io case is a different problem.

Comment 7

[Petru-Mugurel Lingurar [:petru]]

Sure!
I've created https://bugzilla.mozilla.org/show_bug.cgi?id=1717769 based on the reporter comment.