1955112 - Leftover movingtab attribute leaves unresponsive toolbar/urlbar until tab is dragged again

Status: RESOLVED FIXED

(Core :: Widget: Gtk, defect, P2)

Description

[Emilio Cobos Álvarez [:emilio]]

[Tracking Requested - why for this release]: Looks like a recent regression that leaves the browser in a bad state.

This happened to me today (was chatting with my brother, not sure if I moved a tab somewhere or something), but same has happened to :erosman (cc'd) recently.

Firefox gets in a state where everything looks good, but clicking on the urlbar or what not doesn't work.

Investigating a bit, there was a movingtab attribute in the toolbox that somehow caused this. Just adding this attribute manually causes the same broken state (though of course the question is why did it remain set incorrectly).

Dao, have there been recent tab dragging changes or relevant styling changes around this area?

This looks like a recent regression given both erosman and me have hit it these last couple days. But not being able to repro means not being able to bisect, I don't really know what I did to get into that state... :(

Comment 1

[Emilio Cobos Álvarez [:emilio]]

https://searchfox.org/mozilla-central/rev/81b1c51a6b1cfe1dc2a5c8b39f3346bc1d167790/browser/themes/shared/tabbrowser/tabs.css#158 is what causes the navbar to be not interactable at all...

Comment 2

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

The bug is marked as tracked for firefox138 (nightly). We have limited time to fix this, the soft freeze is in 7 days. However, the bug still isn't assigned.

:cbellini, could you please find an assignee for this tracked bug? If you disagree with the tracking decision, please talk with the release managers.

For more information, please visit BugBot documentation.

Comment 3

[Mike Conley (:mconley) (:⚙️) (PTO Dec 22 - Jan 2)]

This might be a dupe of bug 1952530.

Comment 4

[Dão Gottwald [:dao]]

(In reply to Mike Conley (:mconley) (:⚙️) from comment #3)

This might be a dupe of bug 1952530.

I think it's different. Seems similar to bug 1954163, which may have fixed this. Unfortunately without steps here it's difficult to say for sure. We should at least read through the drag and drop code again and make sure we properly exit moving tab mode when the drag session ends.

Comment 5

[Dão Gottwald [:dao]]

Attachment: Bug 1955112 - Finish tab moving animation when a drag session wasn't ended properly. r?sthompson,dwalker,jswinarton

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/aa8a29bd1fb9
Finish tab moving animation when a drag session wasn't ended properly. r=dwalker,tabbrowser-reviewers

Comment 7

[Narcis Beleuzu [:NarcisB]]

https://hg.mozilla.org/mozilla-central/rev/aa8a29bd1fb9

Comment 8

[Dão Gottwald [:dao]]

For the record, I've effectively backed this out in bug 1957434, based on the assumption that bug 1954163 had already fixed the underlying problem here. Please do let me know if you see this happen again.

Comment 9

[Emilio Cobos Álvarez [:emilio]]

Actually just got this today again...

Comment 10

[Dão Gottwald [:dao]]

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

Actually just got this today again...

Any clues as to how you may have triggered it?

Comment 11

[Emilio Cobos Álvarez [:emilio]]

Unfortunately not... My computer was rather busy with a build, but I don't recall actively dragging a tab (maybe accidental drag?)

Comment 12

[Dão Gottwald [:dao]]

Hm, okay, I'm hesitant to try to hack around this again like I tried before. :/ I do wonder if we're not using the Drag and Drop API quite the right way, or if there's an underlying Gecko bug here.

Comment 13

[Emilio Cobos Álvarez [:emilio]]

It may be a wayland bug, IIUC both me and erosman are on Linux/Wayland...

Comment 14

[Dão Gottwald [:dao]]

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

It may be a wayland bug, IIUC both me and erosman are on Linux/Wayland...

erosman, can you confirm this?

I'm gonna go ahead and move this to Widget: Gtk based this assumption, since we don't have other reports about this at the moment aside from bug 1954163 which was indeed a front-end bug.

Comment 15

[erosman [:erosman]]

erosman, can you confirm this?

Yes... Ubuntu 24.04 Wayland

Some observations that may be relevant (or not) ...

• Although I have not experienced unresponsive urlbar in the recent days, I have regularly experienced the whole tab becoming unresponsive for a few seconds during the last couple of weeks.
• When switching between the tabs, quite often the mouse-wheel does not work, until I click on the page (i.e. switching tabs doesn’t make the page active).

Please note that although I move tabs regularly and rapidly switch between them, I rarely keep more than 10 tabs open (no pinned tabs), and 99% of the times, I only use a single window.

Comment 16

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

This is a reminder regarding comment #2!

The bug is marked as tracked for firefox138 (beta). We have limited time to fix this, the soft freeze is in 14 days. However, the bug still isn't assigned.

Comment 17

[Dão Gottwald [:dao]]

Karl or Martin, any chance you could help with this?

Comment 18

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

Please run with MOZ_LOG="WidgetDrag:5" may help, you should see 'invisibleSourceDragEnd' log event that the D&D is finished on toolkit level.

Comment 19

[Dão Gottwald [:dao]]

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

Please run with MOZ_LOG="WidgetDrag:5" may help, you should see 'invisibleSourceDragEnd' log event that the D&D is finished on toolkit level.

erosman and emilio, could you please give this a try?

Comment 20

[Emilio Cobos Álvarez [:emilio]]

I can try, though I only repro'd once every couple days which makes it rather hard...

Comment 21

[erosman [:erosman]]

I got the bug just now. Here are some observations:

• The bug occurred while I was on a tab, not moving tabs
• I had moved a single tab a while before that
• The entire urllbar has pointer-events: none;
• On tab-bar, everything works (open, new tab, switch tab, minimise, maximise, etc). however, close tab doesn’t work for any any of the open tabs
• The Bookmark toolbar works fine
• I haven’t enabled MOZ_LOG (last time I enabled it for another bug, it caused issues on my set-up)

However, I moved a tab and created a group and everything got back to normal.

Comment 22

[erosman [:erosman]]

I got the bug now, again (latest Nightly). I had not moved any tabs so the bug may not be the result of moving tabs.
However, moving a tab canceled the bug effect.

Comment 23

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

This is a reminder regarding comment #2!

The bug is marked as tracked for firefox138 (beta). We have limited time to fix this, the soft freeze is in 8 days. However, the bug still isn't assigned.

Comment 24

[Dão Gottwald [:dao]]

Realistically this is a wontfix for 138 at this point. :/

Comment 25

[21egg0tf]

(In reply to erosman [:erosman] from comment #21)

I got the bug just now. Here are some observations:

• The bug occurred while I was on a tab, not moving tabs
• I had moved a single tab a while before that
• The entire urllbar has pointer-events: none;
• On tab-bar, everything works (open, new tab, switch tab, minimise, maximise, etc). however, close tab doesn’t work for any any of the open tabs
• The Bookmark toolbar works fine
• I haven’t enabled MOZ_LOG (last time I enabled it for another bug, it caused issues on my set-up)

However, I moved a tab and created a group and everything got back to normal.

This describes exactly what I am experiencing. I filed a bug report for this here: bug 1964250.
It happens a lot more often to me than what people describe here. Every time I use Firefox the issue appears after 10–15 minutes. Today it appeared right after starting Firefox, disappeared after dragging a tab and reappeared a few minutes later. Knowing that I can stop it by moving a tab helps a lot though!

Comment 26

[21egg0tf]

I am on Wayland as well.

Comment 28

[:gerard-majax]

Attachment: firefox-dnd-freeze.log

Bug happened circa 12:15~18 UTC and self-fixed by ~12:43 UTC

Triggered (?) when I right click a newly opened tab and selected move to a new window, maybe I misdrag something.

Self-fixed by :stransky's suggestion of dragging something: opened a new tab in the window created earlier and dragged back to the main window on the vertical sidebar.

Comment 29

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

Can you check where on the log you see the freeze? Because it looks like complete D&D session. But if you see the freeze I'd expect to see unfinished D&D there which is completed the next D&D which fixes it.
Thanks.

Comment 30

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

Okay, if the timing is correct there's the relevant part:

2025-05-06 12:00:39.336194 UTC - [Parent 1892668: Main Thread]: D/WidgetDrag [D 0][77a59363a400] nsDragSession::SourceBeginDrag(77a5855039d0)
2025-05-06 12:00:39.336197 UTC - [Parent 1892668: Main Thread]: D/WidgetDrag [D 0][77a59363a400] nsDragSession::SetDragIcon(77a5855039d0)
2025-05-06 12:00:39.336205 UTC - [Parent 1892668: Main Thread]: D/WidgetDrag [D 0][77a59363a400]   set drag popup [77a5c4dcd300]
2025-05-06 12:00:39.337203 UTC - [Parent 1892668: Main Thread]: D/WidgetDrag [D 0][77a59363a400]   GdkDragContext [77a5855039d0] nsWindow [77a62fad8700]
2025-05-06 12:00:44.308043 UTC - [Parent 1892668: Main Thread]: D/WidgetDrag [D 0][77a59363a400] nsDragSession::EndDragSessionImpl(0) 0

2025-05-06 12:42:59.453886 UTC - [Parent 1892668: Main Thread]: D/WidgetDrag [D 0][77a5e79ab100] nsDragSession::nsDragSession()
2025-05-06 12:42:59.454156 UTC - [Parent 1892668: Main Thread]: D/WidgetDrag [D 0][77a5e79ab100] nsDragSession::InvokeDragSession
2025-05-06 12:42:59.454169 UTC - [Parent 1892668: Main Thread]: D/WidgetDrag [D 0][77a5e79ab100] nsDragSession::InvokeDragSessionImpl
2025-05-06 12:42:59.454174 UTC - [Parent 1892668: Main Thread]: D/WidgetDrag [D 0][77a5e79ab100]   numDragItems = 1
2025-05-06 12:42:59.454177 UTC - [Parent 1892668: Main Thread]: D/WidgetDrag adding target application/x-moz-tabbrowser-tab
2025-05-06 12:42:59.454180 UTC - [Parent 1892668: Main Thread]: D/WidgetDrag adding target text/x-moz-text-internal
2025-05-06 12:42:59.454509 UTC - [Parent 1892668: Main Thread]: D/WidgetDrag invisibleSourceDragBegin (77a585f56920)

So nsDragSession::EndDragSessionImpl(0) 0 may be the last D&D operation which puts Firefox to frozen state.

Comment 31

[Kestrel]

STR:

1. Visit https://inv.nadeko.net/watch?v=BKLDHMka3zg (Invidious youtube frontend) on Ubuntu 25.04 or Windows 11.
2. Play video in PiP (Ctrl+Shift+]).
3. Create a new tab and drag it for some time (no need to change position) until it stops responding.

Expected:
Tab dragging and interface remains responsive.

Actual:
Dragged tab freezes, error appears in console (Linux only), after releasing tab it remains frozen and toolbar unresponsive. Can be corrected by dragging frozen tab again (wasn't previously the case).

Browser Console error on Linux:

Uncaught TypeError: can't access property "mozItemCount", dt is null
    getDropEffectForTabDrag chrome://browser/content/tabbrowser/tabs.js:3197
    on_dragover chrome://browser/content/tabbrowser/tabs.js:889
    handleEvent chrome://browser/content/tabbrowser/tabs.js:3033

Happens regardless of Wayland/XWayland/X11, Windows/Linux,browser.tabs.groups.enabled, browser.tabs.hoverPreview.enabled or nglayout.enable_drag_images. Also happens with Youtube but less common.

Commit aa8a29bd1fb9 in Comment 6 (reverted in Bug 1957434) was a major improvement, while the tab still froze while dragging, releasing returned it to its original location and the toolbar remained responsive.

Reproducible back to 2021-01-01, beyond which site does not allow passing bot challenge. Seems to be easier to encounter in last few months, it can happen without a PiP video playing if profile has many tabs (thousands).

Comment 32

[Kestrel]

Attachment: Dragged tab getting stuck on Windows 11 making toolbar unresponsive

Comment 33

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

I reproduced that locally, there's a minimal log from the freeze:

[Parent 5427: Main Thread]: D/WidgetDrag [D 0][7f1d645b6100] nsDragSession::nsDragSession()
[Parent 5427: Main Thread]: D/WidgetDrag [D 0][7f1d645b6100] nsDragSession::InvokeDragSession
[Parent 5427: Main Thread]: D/WidgetDrag [D 0][7f1d645b6100] nsDragSession::InvokeDragSessionImpl
[Parent 5427: Main Thread]: D/WidgetDrag [D 0][7f1d645b6100]   numDragItems = 1
[Parent 5427: Main Thread]: D/WidgetDrag adding target application/x-moz-tabbrowser-tab
[Parent 5427: Main Thread]: D/WidgetDrag adding target text/x-moz-text-internal
[Parent 5427: Main Thread]: D/WidgetDrag invisibleSourceDragBegin (7f1d867a82f0)
[Parent 5427: Main Thread]: D/WidgetDrag [D 0][7f1d645b6100] nsDragSession::SourceBeginDrag(7f1d867a82f0)
[Parent 5427: Main Thread]: D/WidgetDrag [D 0][7f1d645b6100] nsDragSession::SetDragIcon(7f1d867a82f0)
[Parent 5427: Main Thread]: D/WidgetDrag [D 0][7f1d645b6100]   set drag popup [7f1d7afea500]
[Parent 5427: Main Thread]: D/WidgetDrag [D 0][7f1d645b6100]   GdkDragContext [7f1d867a82f0] nsWindow [7f1d766f9700]
[Parent 5427: Main Thread]: D/WidgetDrag [D 0][7f1d645b6100] nsDragSession::EndDragSessionImpl(0) 0

Comment 36

[Emilio Cobos Álvarez [:emilio]]

Given that it's reproducible on windows too (comment 31) should we re-land the workaround at least in the interim?

Comment 39

[Dão Gottwald [:dao]]

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

Given that it's reproducible on windows too (comment 31) should we re-land the workaround at least in the interim?

The workaround caused bug 1957434 so unfortunately it's not that easy. :/

Comment 40

[Dão Gottwald [:dao]]

(In reply to Kestrel from comment #31)

STR:

1. Visit https://inv.nadeko.net/watch?v=BKLDHMka3zg (Invidious youtube frontend) on Ubuntu 25.04 or Windows 11.
2. Play video in PiP (Ctrl+Shift+]).
3. Create a new tab and drag it for some time (no need to change position) until it stops responding.

Expected:
Tab dragging and interface remains responsive.

Actual:
Dragged tab freezes, error appears in console (Linux only), after releasing tab it remains frozen and toolbar unresponsive. Can be corrected by dragging frozen tab again (wasn't previously the case).

Browser Console error on Linux:

Uncaught TypeError: can't access property "mozItemCount", dt is null
    getDropEffectForTabDrag chrome://browser/content/tabbrowser/tabs.js:3197
    on_dragover chrome://browser/content/tabbrowser/tabs.js:889
    handleEvent chrome://browser/content/tabbrowser/tabs.js:3033

Happens regardless of Wayland/XWayland/X11, Windows/Linux,browser.tabs.groups.enabled, browser.tabs.hoverPreview.enabled or nglayout.enable_drag_images. Also happens with Youtube but less common.

Commit aa8a29bd1fb9 in Comment 6 (reverted in Bug 1957434) was a major improvement, while the tab still froze while dragging, releasing returned it to its original location and the toolbar remained responsive.

Reproducible back to 2021-01-01, beyond which site does not allow passing bot challenge. Seems to be easier to encounter in last few months, it can happen without a PiP video playing if profile has many tabs (thousands).

Are we sure this is the same issue? I don't recall having seen anyone else report the can't access property "mozItemCount", dt is null error.

Comment 41

[Kestrel]

Yes, there is a leftover movingtab attribute on the toolbox which is the original issue described in Comment 0. The console error is tangential and not necessary for the bug to occur on Windows and the Comment 6 patch fixed the unresponsive toolbar despite the error still appearing.

Comment 42

[Dão Gottwald [:dao]]

I think it may be wise to track a few things separately here. E.g. figure out how and why PiP interferes with drag and drop (might be a Gecko bug?), add a front-end workaround for DragEvent.dataTransfer being null (https://html.spec.whatwg.org/multipage/dnd.html#the-dragevent-interface says it's indeed optional), and keep tracking the possible Wayland bug here since it seems most reports we got were on Linux / Wayland.

Comment 43

[Juan Escudero]

I also have this problem (from https://bugzilla.mozilla.org/show_bug.cgi?id=1964234), snap firefox 138.0.3-1 in Ubuntu 24.04 LTS.

Comment 46

[Facundo Gaich]

Hi, I'm also hit by this bug

Firefox Linux (mozilla deb)
138.0.4 (64-bit)
Wayland

I have the same log output with MOZ_LOG="WidgetDrag:5" up to when the issue occurs:

[Parent 26287: Main Thread]: D/WidgetDrag [D 0][7ff8b3564a00] SourceEndDragSession(7ff8abec83a0) result GTK_DRAG_RESULT_NO_TARGET
[Parent 26287: Main Thread]: D/WidgetDrag invisibleSourceDragEnd(7ff8abec83a0)
[Parent 26287: Main Thread]: D/WidgetDrag [D 0][7ff8b3564a00] SourceEndDragSession(7ff8abec83a0) result GTK_DRAG_RESULT_SUCCESS
[Parent 26287: Main Thread]: D/WidgetDrag [D 0][7ff8a39f9700] nsDragSession::nsDragSession()
[Parent 26287: Main Thread]: D/WidgetDrag [D 0][7ff8a39f9700] nsDragSession::InvokeDragSession
[Parent 26287: Main Thread]: D/WidgetDrag [D 0][7ff8a39f9700] nsDragSession::InvokeDragSessionImpl
[Parent 26287: Main Thread]: D/WidgetDrag [D 0][7ff8a39f9700]   numDragItems = 1
[Parent 26287: Main Thread]: D/WidgetDrag adding target application/x-moz-tabbrowser-tab
[Parent 26287: Main Thread]: D/WidgetDrag adding target text/x-moz-text-internal
[Parent 26287: Main Thread]: D/WidgetDrag invisibleSourceDragBegin (7ff8b7f922f0)
[Parent 26287: Main Thread]: D/WidgetDrag [D 0][7ff8a39f9700] nsDragSession::SourceBeginDrag(7ff8b7f922f0)
[Parent 26287: Main Thread]: D/WidgetDrag [D 0][7ff8a39f9700] nsDragSession::SetDragIcon(7ff8b7f922f0)
[Parent 26287: Main Thread]: D/WidgetDrag [D 0][7ff8a39f9700]   set drag popup [7ff8a6b70100]
[Parent 26287: Main Thread]: D/WidgetDrag [D 0][7ff8a39f9700]   GdkDragContext [7ff8b7f922f0] nsWindow [7ff8b9beb400]
[Parent 26287: Main Thread]: D/WidgetDrag [D 0][7ff8a39f9700] nsDragSession::EndDragSessionImpl(0) 0

Moving a tab again fixes it

Comment 47

[regunakyle]

I am on Fedora 42 KDE and is also affected by this bug.
After browsing for a while, the close tab button of tabs have no effect, and the buttons on the toolbar (including extensions) also become unresponsive.

Firefox version: 138.0.3

Comment 48

[skoruppa]

I'm also affected by this, and this happens each time I use Firefox after about 10-15m. It was not happening until recently, so this is something new.

Firefox 138.0.4 from the Mozilla Firefox Debian Package on Ubuntu 24.10 with Wayland and Gnome

Comment 49

[saurabh.minni]

I too face the issue with Firefox 138.0.3 (64-bit) on Kubuntu 24.10

Operating System: Kubuntu 24.10
KDE Plasma Version: 6.1.5
KDE Frameworks Version: 6.6.0
Qt Version: 6.6.2
Kernel Version: 6.11.0-25-generic (64-bit)
Graphics Platform: Wayland
Processors: 8 × Intel® Core™ i5-8250U CPU @ 1.60GHz
Memory: 19.3 GiB of RAM
Graphics Processor: Mesa Intel® UHD Graphics 620
Manufacturer: LENOVO
Product Name: 81BG
System Version: Lenovo ideapad 320-15IKB

Comment 50

[Chris]

Also repeatedly getting this using the Firefox 138.0.4 snap on Ubuntu 24.04.2 LTS. I stay logged in for days/weeks at a time a frequently leave firefox running with tabs open. Except I now have to restart it every day or two to workaround this issue.

Name Firefox
Version 138.0.4
Build ID 20250518213244
Distribution ID canonical-002
User Agent Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:138.0) Gecko/20100101 Firefox/138.0
OS Linux 6.11.0-21-generic #21~24.04.1-Ubuntu SMP PREEMPT_DYNAMIC Mon Feb 24 16:52:15 UTC 2
OS Theme Yaru / Yaru
Application Binary /snap/firefox/6198/usr/lib/firefox/firefox

Comment 51

[Emilio Cobos Álvarez [:emilio]]

See above, a workaround that doesn't require restart is dragging a tab around.

Comment 52

[Emilio Cobos Álvarez [:emilio]]

[Tracking Requested - why for this release]: somewhat frequent and very annoying bug.

Comment 53

[Chris]

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

See above, a workaround that doesn't require restart is dragging a tab around.

Thanks. Is this issue likely to be fixed in 139? Is there more information that I can provide in order to increase the chances of it being fixed in 139 or 140?

Comment 54

[Damiano]

I've also been experiencing this bug, only noticed it a couple days ago. I haven't had enough experience with it to notice a pattern for when it's triggered because I usually don't notice it until I try to interact with the toolbar (attempting to refresh a page, close a tab, etc) can't seem to trigger it on purpose by moving around tabs or picture in picture videos, so i'll come back and edit this if I notice a pattern later.

In my experience when it happens, I am still able to switch tabs, and if I double click on any part of the tabs (including the X button) it opens a new tab. the only way for me to close a tab is to right click the tab and close it. Refreshing the page does not work at all, neither does any other button on the toolbar. I can still click on bookmarks.

Firefox version: 138.0.4
OS: Arch Linux x86_64
Linux kernel: 6.12.29-1-lts
DE: KDE Plasma 6.3.5
WM: Kwin Wayland
CPU: Intel i7-10700F @ 4.80GHz
GPU: NVIDIA GeForce RTX 2060

Comment 55

[Lepidium Draba]

I am having this exact issue as well.

Firefox version: 138.0.4
OS: Arch Linux x86_64
Linux kernel: 6.14.6-arch1-1
DE: GNOME 48
WM: Mutter (Wayland)
CPU: Ryzen 7 9800x3d
GPU: NVIDIA GeForce RTX 5070 Ti

Comment 57

[Emilio Cobos Álvarez [:emilio]]

Seems like bug 1967177 comment 0 should be reliable STR. Martin any chance you can reproduce using that and confirm whether it's a bug in the wayland DnD implementation, or in the front-end? Thanks.

Comment 58

[Kestrel]

Bug 1968472 has more reliable STR with regressor marked already.

Comment 59

[jadeia]

Same issue for me:

Lenovo ThinkPad X1 Carbon Gen 11

CPU: 3th Gen Intel® Core™ i5-1335U × 12
GPU: Intel® Iris® Xe Graphics (RPL-U)
Firefox version: 138.0.4
OS: Fedora Linux 42.20250526.0 (Silverblue)
Linux kernel: 6.14.6-300.fc42.x86_64
DE: GNOME 48
WM: Wayland

Comment 60

[Agustín Covarrubias]

Can also replicate on:

CPU: AMD Ryzen 7 7800X3D (16) @ 5.05 GHz
GPU: NVIDIA GeForce RTX 4090 [Discrete]
Firefox version: 138.0.4 (64-bit)
OS: NixOS 25.11 (Xantusia) x86_64
DE: GNOME 48.1
WM: Mutter (Wayland)
Kernel: Linux 6.14.7

Comment 61

[grayich]

Tab close button and URL bar click issues persist in Firefox 139 on KDE Plasma 6.3.5, Wayland (archlinux)

Comment 62

[Kalistia]

Same problem on 138.0.4 (flatpak)

Operating System: Fedora Linux 42
KDE Plasma Version: 6.3.5
KDE Frameworks Version: 6.14.0
Qt Version: 6.9.0
Kernel Version: 6.14.6-300.fc42.x86_64 (64-bit)
Graphics Platform: Wayland

Can close firefox to fix the problem but it comes back randomly

Comment 63

[Emilio Cobos Álvarez [:emilio]]

+1-ing doesn't help. Note also that you don't need to close to fix this, just dragging a tab around does.

Comment 64

[saurabh.minni]

Not seeing this issue now on 138.0.4 (64-bit) after upgrading to Kubuntu 2025.04 5 days ago. Will report back if the status changes.

Comment 65

[Danny]

Happening to me also - 138 / ubuntu 24.10 - gnome

Comment 67

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

Attachment: Bug 1955112 [Wayland] Terminate buggy unfinished D&D operation as DragDrop r?emilio

Comment 68

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

btw. This is caused by Wayland protocol as we're not getting D&D events/correct termination info if D&D finished outside of our window. I guess the regressions bugs attached here only revealed the problem. Bug 1955820 (xdg-toplevel-drag-v1) may help to fix it if we manage to implement it.

Comment 69

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/484b13a181b1
https://hg.mozilla.org/integration/autoland/rev/323d3f649a2d
[Wayland] Terminate buggy unfinished D&D operation as DragDrop r=emilio

Comment 70

[Cristina Horotan [:chorotan]]

https://hg.mozilla.org/mozilla-central/rev/323d3f649a2d

Comment 71

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

The patch landed in nightly and beta is affected.
:stransky, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval. Also, don't forget to request an uplift for the patches in the regression caused by this fix.
  • See https://wiki.mozilla.org/Release_Management/Requesting_an_Uplift for documentation on how to request an uplift.
• If no, please set status-firefox140 to wontfix.

For more information, please visit BugBot documentation.

Comment 72

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

Comment on attachment 9491469 [details]
Bug 1955112 [Wayland] Terminate buggy unfinished D&D operation as DragDrop r?emilio

Beta/Release Uplift Approval Request

• User impact if declined/Reason for urgency: Due to Wayland protocol D&D design we can't clearly identify finished D&D operations outside of Firefox window - in such case the D&D state may end as unfinished on our side and D&D attributes are kept as part of Firefox tab bar UI which makes in inert.
• 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: Medium
• Why is the change risky/not risky? (and alternatives if risky): We change default action for unfinished D&D operations from none to drop. That may lead to unintended tab drop action on tabbar (i.e. detached tab / created new window etc). But it's still better than frozen browser.
• String changes made/needed:
• Is Android affected?: No

Comment 73

[erosman [:erosman]]

We change default action for unfinished D&D operations from none to drop.

I have noticed a new bug since the issue was fixed.
It may not be related, but it could also be related.

Wile on a tab and working with the mouse only, I soddenly end up with the tab opened in a new window.
I am not sure of the STR at the moment, but I will update if I can work it out.

Comment 74

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

(In reply to erosman [:erosman] from comment #73)

We change default action for unfinished D&D operations from none to drop.

I have noticed a new bug since the issue was fixed.
It may not be related, but it could also be related.

Wile on a tab and working with the mouse only, I soddenly end up with the tab opened in a new window.
I am not sure of the STR at the moment, but I will update if I can work it out.

Yes, that's the fix. Instead of drag cancel and UI freeze we terminate it as drag drop. I'll look at it if we can cancel the D&D and terminate it correctly.

Comment 75

[erosman [:erosman]]

I had a strange occurrence just now where the drop-down that shows suggestions as you type in the URL bar became unresponsive in the latest Nightly.
I couldn’t select (no hover, no click response) any item on the drop-down.

Comment 76

[erosman [:erosman]]

Are we sure that the bug is fixed?
I got the bag again while typing in the address-bar, as mentioned above.
All icons on the address bar are inactive on all tab, except the download button (which works on all tabs).
Like before, moving a tab resets the bug.

Ubuntu 24.04
Nightly Build ID 20250603093015

Comment 77

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

Please try to run on terminal with MOZ_LOG="WidgetDrag:5", reproduce the issue and attach the log here.
Thanks!

Comment 78

[Kestrel]

(In reply to erosman [:erosman] from comment #76)

Are we sure that the bug is fixed?

Bug 1968472 is no longer reproducible for me in latest Nightly 141.0a1 (2025-06-04).

I got the bag again while typing in the address-bar, as mentioned above.

I filed something similar as Bug 1970398.

Comment 79

[Donal Meehan [:dmeehan]]

:stranksy, I see the beta uplift request was removed, but is there still a benefit in requesting uplift here?

Comment 80

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

(In reply to Donal Meehan [:dmeehan] from comment #79)

:stranksy, I see the beta uplift request was removed, but is there still a benefit in requesting uplift here?

Frankly I don't know as there are mixed reports and I can't reproduce that reliably myself.

Comment 81

[Donal Meehan [:dmeehan]]

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

(In reply to Donal Meehan [:dmeehan] from comment #79)

:stranksy, I see the beta uplift request was removed, but is there still a benefit in requesting uplift here?

Frankly I don't know as there are mixed reports and I can't reproduce that reliably myself.

Fair, it's not a new bug in Fx140 so will be cleaner to ride with Fx141

Comment 89

[:Gijs (he/him)]

If we don't think that the patch here is suitable for uplift, can/should we add an interim upliftable workaround on the frontend? For instance, while the movingtab attribute is present, can we detect mousemoves that happen without the mouse button being down / without having a datatransfer, or clicks that happen on the toolbar-side padding of the tabstrip (so without a tab element being the target and not above the boundary of the toolbar) so that we correct state at that point?

I ask because this is collecting dupes at a rate of knots so it would be nice if people don't have to wait another 4 weeks for a fix on the release channel, especially with the uncertainty about the side effects of this fix from bug 1970398 and the other post-fix comments here.

Comment 90

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

I think we can uplift it - it should not cause any regression or it should not be worse. The concern here is about inefficiency of the patch.

Comment 91

[Dão Gottwald [:dao]]

By uplifting you mean to 140? Seems a bit late, and wouldn't buy us 4 weeks at this point. The planned 140.0.x release is on July 8, and 141 releases on July 22.

Comment 92

[Ina Popescu, Desktop QA]

I've tried to reproduce this issue a few times on Ubuntu 22.04 (Wayland) using Nightly 139.0a1 following these STR:

• Open a new tab
• Click and drag the tab around (either move it or just drag without changing position)
• Release the drag outside the window or hold it for a few seconds before releasing

I haven't been able to reproduce the issue so far. Could anyone who has encountered it confirm if it's still happening in the latest Nightly 142.0a1 and Firefox 141.0b5? Thank you.

Comment 93

[Kestrel]

(In reply to Ina Popescu, Desktop QA from comment #92)

I haven't been able to reproduce the issue so far.

Try using the Bug 1968472 STR.

Comment 94

[Ina Popescu, Desktop QA]

(In reply to Kestrel from comment #93)

(In reply to Ina Popescu, Desktop QA from comment #92)

I haven't been able to reproduce the issue so far.

Try using the Bug 1968472 STR.

Thanks for the suggestion. I tried to reproduce this on Ubuntu 22.04 with Wayland using Nightly 140.0a1, but I haven’t seen the issue.
I followed the STR described in Bug 1968472 (left-click and hold on a tab, right-click, drag, then release), but the toolbar remained responsive for me.

Comment 95

[Gary van der Merwe]

Please can the fix for this be back porting to 140 ESR, as for ESR users, this would be a regression when upgrading from 128 ESR.

Comment 96

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

Comment on attachment 9491469 [details]
Bug 1955112 [Wayland] Terminate buggy unfinished D&D operation as DragDrop r?emilio

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: Firefox UI is not responding after randomly performed D&D - that can happens after any short mouse operations over titlebar.
• User impact if declined:
• Fix Landed on Version: 141
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Not risky, we changed D&D termination state for wayland worakound as finished.

Comment 97

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9491469 [details]
Bug 1955112 [Wayland] Terminate buggy unfinished D&D operation as DragDrop r?emilio

Approved for 140.2esr.

Comment 98

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-esr140/rev/f4ccb9bf5cdd