1897115 - [X11/XWayland] Loss of drag-and-drop functionality in Firefox 126.0

Status: VERIFIED FIXED

(Core :: Widget: Gtk, defect)

Description

[[:Bibbles]]

Attachment: Firefox_126.0_drag_n_drop_problem.gif

Steps to reproduce:

My system:

OS: Xubuntu 22.04.3
Kernel version: 5.15.0-107-generic
Firefox 126.0 (installed with APT from official Mozilla PPA)
Input device: Wacom Intuos 4 pen tablet (PTK-640)

Steps to reproduce:

1 Open Firefox 126.0 and go to any website containing text and/or images.
2 Select some text or an image and drag it some distance and drop it back in the open window.
3 Now try to repeat this again. If the bug is present, you will find that drag-and-drop functionality has seized working in Firefox
and it is not possible to select and drag drop images, texts, URLs, tabs etc.
4 Either restart Firefox or do the following to restore drag-and-drop functionality:
a Open another application like a text editor.
b Enter some random text, select it en drag it unto the URL-bar area in Firefox.
This will cause Firefox to try and open the selected text as if it were a URL.
c After this, try step 1 again to see if drag-and-drop functionality has returned.
You will find drag-and-drop functionality working again, but by performing this action the problem returns and drag-and-drop functionality seizes again.

See also the included animated .gif-file

Actual results:

After upgrading to Firefox 126.0 I've noticed same odd behavior in Firefox. Whenever I select text or images on a site, drag them inside the window and drop them, drag-and-drop functionality in Firefox seizes and it becomes impossible to select, drag-and-drop any selected texts, images, tabs or other items in Firefox.

What I tried:

• Different linux-kernel (6.5.0-35-generic) -> The problem remains.
• Different versions of Firefox -> Only Firefox versions 126.0 and above produce this problem!
• Different APT sources and snap -> Firefox from all (official) APT sources and snap produce the same problem.
• Dragging and dropping with a normal mouse AND Wacom plugged -> produced the problem..
  ..But dragging and dropping with a mouse and the Wacom UNPLUGGED -> resolved the problem!
• I tested it on a different computer running Xubuntu 22.04 and Firefox 126.0 but a different Wacom model -> The same problem.
• I tested this also on a clean live USB Xubuntu 22.04, installed Firefox 126.0 -> Same problem.
• I tested this on Xubuntu 22.04 running on Virtualbox -> No problems.
• I asked and got confirmation from a user with the same setup at #xubuntu irc -> He confirmed the problem and suggested to use the Firefox 126.0 ESR version.
  This version (firefox-esr 155.11) did not produce the problem.
• This was also tested on Xubuntu 24.04, but the problem did not come up.

Expected results:

Drag-and-drop functionality should not seize after an initial drag-and-drop action.

A solution:

Not a real fix but a good workaround is to use the firefox-esr version instead of Firefox. I tested firefox-esr 115.11 (based on Firefox 126.0) on Xubuntu 22.04 and it works as expected. Upgrading to Xubuntu 24.04 should also 'fix' this problem.

Comment 1

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

The Bugbug bot thinks this bug should belong to the 'Core::DOM: Copy & Paste and Drag & Drop' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Sean Feng [:sefeng][PTO, back July 1st]]

Hey, Is this a regression in 126? If so, can you try to use https://mozilla.github.io/mozregression/ to find the regression range? Thanks!

Comment 3

[[:Bibbles]]

(In reply to Sean Feng [:sefeng] from comment #2)

Hey, Is this a regression in 126? If so, can you try to use https://mozilla.github.io/mozregression/ to find the regression range? Thanks!

Hi Sean Feng!

I'm a bit new to all of this, but I managed to download and run mozregression. I used version "125.0" as the last known 'good' version and "126.0" as the first 'bad' one. It eventually narrowed it all down to the output below. I'm not an expert but "pending drag context" indeed sounds like it might have something to do with the bug I encountered.

I hope this helps?
-Bibbles

-- mozregression-GUI_OUTPUT ----------------------

app_name: firefox
build_date: 2024-03-28 03:21:28.010000
build_file: /home/pjotter/.mozilla/mozregression/persist/610635ed76ae-pgo--autoland--target.tar.bz2
build_type: integration
build_url: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/BPjtBPFoRr6_wH6OqXQv4Q/runs/0/artifacts/public%2Fbuild%2Ftarget.tar.bz2
changeset: 610635ed76ae571c7dd7084706897ac6dce68cea
pushlog_url: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=83bed5a23e696299854bce3fdbb239795160cfc5&tochange=610635ed76ae571c7dd7084706897ac6dce68cea
repo_name: autoland
repo_url: https://hg.mozilla.org/integration/autoland
task_id: BPjtBPFoRr6_wH6OqXQv4Q

---

2024-05-16T18:06:43.072000: DEBUG : Found commit message:
Bug 1875031 - Don't keep pending drag context alive after EndDragSession. r=stransky

Otherwise we might keep receiving drag motion events, which are
unexpected and can confuse other code.

Differential Revision: https://phabricator.services.mozilla.com/D205698

2024-05-16T18:06:43.072000: DEBUG : Did not find a branch, checking all integration branches
2024-05-16T18:06:43.077000: INFO : The bisection is done.
2024-05-16T18:06:43.082000: INFO : Stopped

Comment 4

[Sean Feng [:sefeng][PTO, back July 1st]]

That indeed sounds suspicious.

Emilio, mind confirm this?

Comment 5

[Emilio Cobos Álvarez (:emilio)]

I lack the hardware to reproduce this, and at least on Arch I cannot reproduce with the mouse, neither in GNOME nor KDE...

Martin, any idea? If not, we might as well back out my patch I guess, since bug 1875031 was also fixed in KWin's side....

Comment 6

[bxkx]

It's not just a Wacom Tablet thing. I have the same issue with regular desktop PC. Same behavior, I randomly can't drag & drop any text, tabs etc. Restarting Firefox or dropping something into the address bar from e.g. a text editor restores the functionality until it stops again.

No issues with previous FF version.
I'm using X11 on an up to date Arch Linux w/ Mesa drivers for RX 6600 and Intel 12th gen i5 CPU

Comment 7

[[:Bibbles]]

(In reply to bxkx from comment #6)

It's not just a Wacom Tablet thing. I have the same issue with regular desktop PC. Same behavior, I randomly can't drag & drop any text, tabs etc. Restarting Firefox or dropping something into the address bar from e.g. a text editor restores the functionality until it stops again.

No issues with previous FF version.
I'm using X11 on an up to date Arch Linux w/ Mesa drivers for RX 6600 and Intel 12th gen i5 CPU

That's interesting bxkx. And thank you for this information! The only other person I found so far that experienced the same problem, was someone also using a Wacom. So, I assumed it might have something to do with that. I just re-tested the problem using only a mouse (wacom unplugged) and managed to reproduce the problem after several tries! So, it does seem that this problem also occurs with a mouse only. Only less frequent than with using a Wacom Tablet Pen. With the Wacom Pen Tablet it's very consistent and happens almost every single time.

I also noted that the problem occurs after a drag-and-drop action with a slight 'stutter' when dropping the selected item back on the window. Normally when I drag-and-drop items, they float smoothly back to their original position, but when this problem occurs, the items seem to stop floating and halt somewhere on the way back.

Maybe it's also noteworthy to say that my system is also using X11, not Wayland. It's an amd64 system with an AMD CPU from the Phenom series.

Comment 8

[Emilio Cobos Álvarez (:emilio)]

It might be due to X11 vs. wayland (I haven't tried to repro under X11 yet).

Any interesting DE? Or just GNOME / KDE?

For any of the folks that can repro reliably, can you try on the latest nightly? Martin has done a lot of work in the D&D implementation, so it might be that it's already fixed.

Comment 9

[[:Bibbles]]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #8)

It might be due to X11 vs. wayland (I haven't tried to repro under X11 yet).

Any interesting DE? Or just GNOME / KDE?

For any of the folks that can repro reliably, can you try on the latest nightly? Martin has done a lot of work in the D&D implementation, so it might be that it's already fixed.

Hello Emilio,

I just tried latest nightly firefox-128.0a1.en-US.linux-x86_64, but the bug is still present.
My system runs Xubuntu 22.04.3, so it's a Xfce4 desktop environment.

Comment 10

[Alice0775 White]

I can reproduce the issue on Firefox128.0a1 Kubuntu22.14 KDE+X11 and Ubuntu22.04 GNOME+Xwayland(export MOZ_ENABLE_WAYLAND=0), but not on Ubuntu22.04 GNOME+Wayland.

Comment 13

[bxkx]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #8)

Any interesting DE? Or just GNOME / KDE?

Forgot to mention, No full DE here, just using Openbox as window manager.
I also noticed that when the issue occurs, hovering over tabs or links on pages wont show the little tool tip with the full title either.
I just have no idea how to make it happen. I don't think I do anything specific and it just happens at some point, but I'm not sure. I haven't really figured it out yet.

Comment 14

[Martin Stránský [:stransky] (ni? me)]

Please try to capture broken scenario and attach log from it. Run Firefox on terminal as:

MOZ_LOG="WidgetDrag:5" firefox > log.txt 2>&1

and if you reproduce it attach log.txt here.
Thanks.

Comment 15

[Martin Stránský [:stransky] (ni? me)]

From the screencast the D&D operation is not finished so we can't start another one. Will check that on log when it's provided.

Comment 16

[[:Bibbles]]

Attachment: log.txt

Output from command MOZ_LOG="WidgetDrag:5" firefox > log.txt 2>&1:

• Selected some text
• Dragged the selected text and dropped it again (triggered bug)
• Closed firefox

Comment 17

[[:Bibbles]]

(In reply to Martin Stránský [:stransky] (ni? me) from comment #14)

Please try to capture broken scenario and attach log from it. Run Firefox on terminal as:

MOZ_LOG="WidgetDrag:5" firefox > log.txt 2>&1

and if you reproduce it attach log.txt here.
Thanks.

Hello Martin,

I've done as you requested and attached the log.txt

Comment 18

[Martin Stránský [:stransky] (ni? me)]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #5)

I lack the hardware to reproduce this, and at least on Arch I cannot reproduce with the mouse, neither in GNOME nor KDE...

Martin, any idea? If not, we might as well back out my patch I guess, since bug 1875031 was also fixed in KWin's side....

Yes, we should revert Bug 1875031 at some point.

SourceEndDragSession() call finishes the D&D operation on Firefox side but works like a shortcut when we call it from invisibleSourceDragFailed(). We need to clear the resources (if we do it) from invisibleSourceDragEnd / drag_end signal which is the real D&D endpoint from OS/Gtk perspective.

I'd like to check if we can get D&D data request from Firefox after invisibleSourceDragEnd / drag_end. In such case we'll need to keep the data in cache as we don't have valid drag context after drag_end.

Comment 19

[Martin Stránský [:stransky] (ni? me)]

Attachment: Bug 1897115 [Linux] Don't clear D&D resources on nsDragService::EndDragSession() r?emilio

Comment 20

[Martin Stránský [:stransky] (ni? me)]

Attachment: Bug 1897115 [Linux] Use direct MIME type query at invisibleSourceDragFailed() r?emilio

We can't use IsDragFlavorAvailable() at invisibleSourceDragFailed() as we don't cache MIME types for drags issued by us.

Depends on D210939

Comment 21

[[:Bibbles]]

Should "using Wacom Pen Tablet" be dropped from the bug description, since it has become apparent that users using only a mouse are affected too?

Comment 22

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/9fcfd3692855
[Linux] Don't clear D&D resources on nsDragService::EndDragSession() r=emilio
https://hg.mozilla.org/integration/autoland/rev/750a9d68013b
[Linux] Use direct MIME type query at invisibleSourceDragFailed() r=emilio

Comment 23

[Donal Meehan [:dmeehan]]

Tracking since this is new in Fx126 and picking up duplicates.
Please add a beta and release uplift request on this when ready.
For Fx127 it could make the next beta after it lands in central. Then it could be included in the Fx126 planned dot release.

Comment 24

[Aron Cseh]

https://hg.mozilla.org/mozilla-central/rev/9fcfd3692855
https://hg.mozilla.org/mozilla-central/rev/750a9d68013b

Comment 25

[Liz Henry (:lizzard) (relman/hg->git project)]

Hi Martin, can you request uplift to beta? Thanks!

Comment 26

[Martin Stránský [:stransky] (ni? me)]

Comment on attachment 9402776 [details]
Bug 1897115 [Linux] Don't clear D&D resources on nsDragService::EndDragSession() r?emilio

Beta/Release Uplift Approval Request

• User impact if declined: D&D operations may be broken due to unfinished one.
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): We're reverting previous patch.
• String changes made/needed:
• Is Android affected?: No

Comment 27

[Pascal Chevrel:pascalc]

Martin, should 750a9d68013b also be uplifted to beta or only 9fcfd3692855 is needed?

Comment 28

[Martin Stránský [:stransky] (ni? me)]

We need https://phabricator.services.mozilla.com/D210939 only.

Comment 29

[Pascal Chevrel:pascalc]

Comment on attachment 9402776 [details]
Bug 1897115 [Linux] Don't clear D&D resources on nsDragService::EndDragSession() r?emilio

Thanks, approved for 127 beta 5

Comment 30

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-beta/rev/e36ca21ed5c3

Comment 31

[Donal Meehan [:dmeehan]]

:stransky could you also add a release uplift request on this?
We can aim to include it in the planned Fx126 dot release.

Comment 32

[Martin Stránský [:stransky] (ni? me)]

Comment on attachment 9402776 [details]
Bug 1897115 [Linux] Don't clear D&D resources on nsDragService::EndDragSession() r?emilio

Beta/Release Uplift Approval Request

• User impact if declined: D&D operations may be broken due to unfinished one.
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): We're reverting previous patch.
• String changes made/needed:
• Is Android affected?: Yes

Comment 33

[Catalin Sasca, Desktop QA [:csasca]]

Reproduced the issue on Firefox 126.0 on Ubuntu 22.04 X11 by following the infos provided in Comment 0.

The issue is no longer reproducible on Firefox 127.0b5 and Firefox 128.0a1 (2024-05-23) on the same system.

Comment 34

[[:Bibbles]]

I too can confirm the latest Firefox versions 127.0b5 and 128.0a1 do not produce the bug for me.
Thanks everybody! :)

Comment 35

[Donal Meehan [:dmeehan]]

Comment on attachment 9402776 [details]
Bug 1897115 [Linux] Don't clear D&D resources on nsDragService::EndDragSession() r?emilio

Approved for 126.0.1

Comment 36

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-release/rev/d338ec10a5d6

Comment 38

[Catalin Sasca, Desktop QA [:csasca]]

Verified that the issue is fixed on Firefox 126.0.1 on Ubuntu 22.04 X11.