1755099 - Drag and Drop with Surface Pen Broken as of Firefox 97

Status: RESOLVED DUPLICATE of bug 1692072

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

Description

[John L.]

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

Steps to reproduce:

Update to Firefox 97 and drag and drop with pen becomes broken. Same issue happens with the 100.x nightly build. going back to Firefox 96 fixes the issue, as does installing the ESR release _91.X as of this report).

I tested this on several device/pen combos (Surface Pro/Surface Pen/Windows 10, Lenovo Yoga 920/Lenovo and Wacom AES pens/Windows 11, Surface Pro 8/Surface Slim Pen/Windows 11) and all behave the same broken way when updating to Firefox 97.

I want to emphasize that I did not change any pen driver settings under windows before or after the Firefox update. Simply downgrading back to Firefox 96 or earlier fixes the issue.

Actual results:

Click and hold on an object such as a URL and cannot drag it to the Bookmarks sidebar.
Try to drag icons around while customizing the toolbar and icons cannot be dragged.
Try to select text on a webpage by dragging and nothing happens.
Double-clicking on text sometimes (though not always) selects a single word and gives selection handles like those used on smartphones or touch tablets (almost like it's expecting me to use a fingertip instead of a pen).
Instead of text selection, dragging the pen vertically up or down a web page instead scrolls the page, the same as using fingers on the screen.

Expected results:

The expected behavior is that experienced in Firefox 96 and earlier. Dragging and dropping and selecting text with a digital pen should work like that.

Comment 1

[Botond Ballo [:botond]]

Shot in the dark: does going to about:config and setting widget.disable-swipe-tracker to false change anything?

Comment 2

[John L.]

Widget.disable-swipe-tracker was already set to false. I toggled it to true and back to false (with Firefox restarts in between) and there was no difference.

I would also like to correct an error on my original report: the nightly builds I've been testing with have been version 99.x, not 100.x.

Comment 3

[Timothy Nikkel (:tnikkel)]

Thanks for testing that.

If you want to run https://mozilla.github.io/mozregression/ to narrow down which changeset caused the issue it would help tracking this down immensely.

Comment 4

[John L.]

Okay...I ran mozregression and I am thoroughly confused (not being a programmer myself, I'm sure).

I ran several bisections for releases 95, 96 and 97 and all of them came up bad, meaning the bug was present in all builds.

I then ran single builds for releases 94, 93, 92, and 91 (91 being the current ESR build I am running successfully without the bug). They all came up bad (!).

I ran a single build for release 90 and that came up good (!!).

I then ran a bisection between releases 90 and 91 and those came up mixed (13 builds, 7 bad, 6 good).

This is where I run into the confusion: what do I do now? Is there a log I can upload so you can see which builds are good and which are bad? Do I just copy the good and bad build numbers here?

For reference, the last good build (by date and time) was autoland build 072faa31 on 2021-06-07 15:14:12.709000. The builds before that time were all good.

The first bad build was autoland 7ee5516d on 2021-06-07 15:38:44.198000. All builds I tested from that date/time or newer were bad.

I am confused because the versions don't match what I experienced with the retail/release versions. I did not experience this bug with release 96.0.4 (or with the current 91.6.0esr). The first bad retail release seemed to be 97.0. I am surprised I had to go so far back with mozrefression to find the good versions.

In any case, please let me know what I should do next.

Comment 5

[Timothy Nikkel (:tnikkel)]

Thank you! That gives us exactly the information we need! The reason you had to go back further than you thought is that a feature got enabled in our testing version called Nightly much earlier then it got released to the main Firefox release to give us time to test it. Evidently we missed a problem here before deploying it to the full release.

Regressing changeset is https://hg.mozilla.org/integration/autoland/rev/7ee5516df237fb0f34a1340e8282055f9073b7af
Bug 1707080 - Enable dispatch_by_pointer_messages on Nightly

Comment 6

[Kagami Rosylight [:saschanaz] (they/them)]

This is currently expected, and it's how Microsoft wants a stylus pen to work on Windows:

• https://blogs.windows.com/windows-insider/2017/06/08/announcing-windows-10-insider-preview-build-16215-pc-build-15222-mobile/
• https://twitter.com/JenMsft/status/862706210562220033

This is basically bug 1692072. Unfortunately this behavior is technically required as Microsoft does not allow drag and drop when consuming stylus information. (That means, prior to version 97 we were not consuming stylus information properly.) Chrome and Edge also decided not to support drag and drop, so I currently see no alternative.

Comment 7

[John L.]

Well, if that's the case, that's super annoying and breaks my pen-based web browsing experience entirely. Shoot. I guess I'll stick to the ESR release until such a time as I can't anymore and then...I don't know...

As a regular user, I'd like to plead this: try to customize the Firefox toolbar on a tablet (like a Surface Pro) without a keyboard and mouse attached. Before this bug (and yes, I still think it's a bug), dragging and dropping could be done precisely with the pen. Now, I'm left to move small icons around with my fat finger. On the flipside (and I do realize this is Microsoft's issue, not Firefox's), scrolling the screen with a fat finger is super easy and intuitive because it doesn't really require any of the finer control a pen tip affords.

Additionally, in the current nightly build (99.0a1 2022-02-13 as I write this), dragging and dropping icons, home page entries and bookmarks using a finger is broken as well, meaning the only way to perform these operations is with a touchpad or mouse, neither of which are readily available on a standalone tablet.

Comment 8

[Kagami Rosylight [:saschanaz] (they/them)]

For now you can set dom.w3c_pointer_events.dispatch_by_pointer_messages to false in about:config page and that will restore the previous behavior. But please be assured that it will break advanced stylus features.

Perhaps Firefox should have a user configuration to make a stylus pen behave as a mouse, as the older versions of Firefox did.

Additionally, in the current nightly build (99.0a1 2022-02-13 as I write this), dragging and dropping icons, home page entries and bookmarks using a finger is broken as well, meaning the only way to perform these operations is with a touchpad or mouse, neither of which are readily available on a standalone tablet.

I'd like to learn more about this, could you elaborate more (preferably by posting a new issue)? Thank you!