1979719 - [wayland] Dragged tab sometimes gets stuck leaving toolbar temporarily unresponsive since drag to pin cue added (leftover movingtab attribute)

Status: VERIFIED FIXED

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

Description

[Kestrel]

Attachment: Unresponsive reload button after tab gets stuck while dragging

STR:

1. Start with MOZ_ENABLE_WAYLAND=1 on latest Nightly 143.0a1 on Ubuntu 25.04.
2. Drag a tab a few pixels inside the tab bar with a quick mouse press and release.
3. Hover mouse cursor over the reload button.
4. Repeat steps 2-3 several times until reload button no longer shows hovered state.

Expected:
Drag operation always finishes cleanly and toolbar remains responsive.

Actual:
Tab sometimes gets stuck (toolbox has leftover movingtab attribute) and toolbar remains unresponsive until two left mouse clicks anywhere in the interface. If the window is maximized, the stuck tab is detached into a new window after the two clicks.

Horizontal and vertical tabs affected. Tab getting stuck in wrong position more visible with vertical tabs (related to Bug 1979647).

Does not happen with MOZ_ENABLE_WAYLAND=0.

Windows 11 unaffected.

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=814d099b10c2fc60993cea8af697227e94cdd303&tochange=b9dd6650484e3485f0606a978708e451b781259f

Regressed by Bug 1963552.

Comment 1

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

:nsharpley, since you are the author of the regressor, bug 1963552, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Comment 2

[Nikki Sharpley (:nikkis) (she/her)]

Thanks for reporting! Hmmm, it sounds like finishAnimateTabMove which calls setMovingTabMode may not be called somewhere? https://searchfox.org/mozilla-central/rev/8720f2b501ba984a61b94b2203eb59895042dc84/browser/components/tabbrowser/content/tabs.js#3219
Unfortunately I was unable to reproduce on my Linux machine with Wayland enabled. Rares or Catalin, could you please take a look and see if you are able to reproduce the issue?

Comment 3

[Rares Doghi, Desktop QA]

Hi, Unfortunately I cannot test this on my end because I cant enable Wayland at all, I'm using X11 due to limitations.

Comment 4

[Catalin Sasca, Desktop Test Engineering [:csasca]]

Attachment: Screencast from 2025-07-29 14-46-09.webm

I was able to reproduce it on Firefox 143.0a1 (2025-07-28) on Ubuntu 24.04 with Wayland. I can reproduce it but it takes some time to be able to make the tab stuck as in the video, also nothing is shown in browser console when this happens.

Comment 5

[Kestrel]

Attachment: Reproducibility of stuck tab

I can easily reproduce it almost every time with the right technique. It becomes easier to reproduce with large numbers of tabs which makes dragging increasingly laggy, expanding the affected time window.

Comment 6

[Sarah Clements [:sclements]]

What exactly is the MOZ_ENABLE_WAYLAND pref for? Looking at the codebase, the only thing I can piece together is harness support for certain jobs to run in taskcluster but there must be more to it? And if this issue only happens and with that pref enabled and is not easily reproducible except by Kestrel, then we're going to need someone who's worked on this to take a look.

Emilio, Martin - I see your name on a few patches where this pref is used. Can you help with this please?

Comment 7

[Emilio Cobos Álvarez [:emilio]]

MOZ_ENABLE_WAYLAND is not needed to reproduce this, but it enables "native" wayland support explicitly. It should be the default on most distros nowadays.

Comment 8

[Emilio Cobos Álvarez [:emilio]]

(I haven't been able to repro consistently, either...)

Comment 9

[Sarah Clements [:sclements]]

Okay... so since this was added to a meta bug for fixing drag n'drop work I'm assuming this is going to be handled by you Martin? A response would be helpful, since it was marked as regressed by one of my team's bugs and its also marked as an S2 which means bug bot is going to start being annoying.

Comment 10

[Emilio Cobos Álvarez [:emilio]]

Sarah, if this is regressed by bug 1963552 (sorry, hadn't realized) it would be great if your team could diagnose at least what in that patch caused this? It might be that something in the coordinate spaces isn't right (because linux tends to have a much bigger outerWidth to innerWidth ratio than Windows / macOS), in which case it'd be a bug with the patch.

Comment 11

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

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

:jstutte, could you please find an assignee for this tracked bug? Given that it is a regression and we know the cause, we could also simply backout the regressor. If you disagree with the tracking decision, please talk with the release managers.

For more information, please visit BugBot documentation.

Comment 12

[Nikki Sharpley (:nikkis) (she/her)]

:emilio, I haven't been able to diagnose the cause of the issue, since I cannot reproduce on my Linux device in a Wayland session and there are no console errors reported. The only clue is the leftover movingtab attribute remaining. This sounds like the finishAnimateTabMove function, which calls setMovingTabMode and removes that attribute, may not be called somewhere? https://searchfox.org/mozilla-central/rev/8720f2b501ba984a61b94b2203eb59895042dc84/browser/components/tabbrowser/content/tabs.js#3219
Though I am not sure why my interaction cue patch bug 1963552 would've caused that...

You mentioned perhaps that coordinates spaces may not be right - so I am curious if this patch will solve this bug as a side effect of changing:
let firstBound = pinnedTabsStartEdge - firstMovingTabScreen;
to:
let startBound = this[screenAxis] - firstMovingTabScreen;
in tabs.js.

If you or someone who can reproduce this bug can please check if this patch fixes the issue that would be very helpful. Thank you for chiming in! :)

Comment 13

[Emilio Cobos Álvarez [:emilio]]

Yeah, I haven't been able to repro this either, but that seems believable...

Comment 14

[Stuart Colville [:muffinresearch]]

(In reply to Nikki Sharpley (:nikkis) (she/her) from comment #12)

If you or someone who can reproduce this bug can please check if this patch fixes the issue that would be very helpful. Thank you for chiming in! :)

I am able to reproduce on Ubuntu 24.04 with wayland by dragging a tab upwards very slightly and letting go of the tab it takes a number of attempts to get it to happen. Noting that my local build required running with GDK_BACKEND=wayland MOZ_ENABLE_WAYLAND=1 ./mach run to avoid errors about the wayland display.

I've run a local build which already has the patch from https://phabricator.services.mozilla.com/D258928 applied (via git commit: e8c78cf8bcc494a48cfd5bf251d61b9c7afe0628) and I can still reproduce the issue.

One further note, with the local build (currently pointing at 457ce1c206204a180ead36ef787f992690c3c99f) , it seems once sidebar.verticalTabs.dragToPinPromo.dismissed is set to true I'm no longer able to reproduce the issue.

Comment 15

[Kestrel]

I can still repro on Ubuntu 25.04 (GNOME), Ubuntu 24.04.2 LTS (GNOME) and KUbuntu 25.04 (KDE) on latest Nightly 143.0a1 (2025-08-03) which includes the patch from Bug 1979647. The tab no longer gets stuck between positions with sidebar.verticalTabs.dragToPinPromo.dismissed = true but still does when it is set to false. In both cases the toolbar is unresponsive for two mouse clicks.

Comment 16

[Martin Stránský [:stransky] (ni? me) (PTO till June 6)]

Please run on terminal with MOZ_LOG="WidgetDrag:5" logging to confirm it's caused by D&D Wayland workaround:
https://searchfox.org/mozilla-central/rev/81221d27112f12a67cb86287bf2b3cd9f19373af/widget/gtk/nsWindow.cpp#7537
Thanks.

Comment 17

[Kestrel]

MOZ_LOG="WidgetDrag:5" output:

[Parent 23156: Main Thread]: D/WidgetDrag [D 0][7d338d827f00] nsDragSession::nsDragSession()
[Parent 23156: Main Thread]: D/WidgetDrag [D 0][7d338d827f00] nsDragSession::InvokeDragSession
[Parent 23156: Main Thread]: D/WidgetDrag [D 0][7d338d827f00] nsDragSession::InvokeDragSessionImpl
[Parent 23156: Main Thread]: D/WidgetDrag [D 0][7d338d827f00]   numDragItems = 1
[Parent 23156: Main Thread]: D/WidgetDrag adding target application/x-moz-tabbrowser-tab
[Parent 23156: Main Thread]: D/WidgetDrag adding target text/x-moz-text-internal
[Parent 23156: Main Thread]: D/WidgetDrag invisibleSourceDragBegin (7d3395c83df0)
[Parent 23156: Main Thread]: D/WidgetDrag [D 0][7d338d827f00] nsDragSession::SourceBeginDrag(7d3395c83df0)
[Parent 23156: Main Thread]: D/WidgetDrag [D 0][7d338d827f00] nsDragSession::SetDragIcon(7d3395c83df0)
[Parent 23156: Main Thread]: D/WidgetDrag [D 0][7d338d827f00]   set drag popup [7d3381b68200]
[Parent 23156: Main Thread]: D/WidgetDrag [D 0][7d338d827f00]   GdkDragContext [7d3395c83df0] nsWindow [7d33a9248900]
*unresponsive toolbar*
[Parent 23156: Main Thread]: D/WidgetDrag WaylandDragWorkaround applied [buttonPressCountWithDrag 2], quit D&D session
[Parent 23156: Main Thread]: D/WidgetDrag [D 0][7d338d827f00] nsDragSession::EndDragSessionImpl(0) 1
[Parent 23156: Main Thread]: D/WidgetDrag [D 0][7d338d827f00] nsDragSession::~nsDragSession
[Parent 23156: Main Thread]: D/WidgetDrag [D 0][7d338d827f00] nsDragSession::RemoveTempFiles
*responsive after two clicks*

Comment 18

[Sarah Clements [:sclements]]

Nikki, can you take a look again based on Stuart's STR in comment 14 please?

Comment 19

[Martin Stránský [:stransky] (ni? me) (PTO till June 6)]

Kestrel, is that a complete log? I'd expect more content before the first nsDragSession::InvokeDragSession() - I expect unfinished D&D before it. Can you attach a complete log please?
Thanks.

Comment 20

[Kestrel]

That is the complete log for the first D&D operation since startup and is the same for subsequent drag failures.

Comment 21

[Martin Stránský [:stransky] (ni? me) (PTO till June 6)]

I can reproduce it in debug mode when browser response is slow. Looks like race in event processing.

Comment 22

[Martin Stránský [:stransky] (ni? me) (PTO till June 6)]

I think there's the difference here:

Correct behavior:

[Parent 167077: Main Thread]: D/WidgetDrag [D 0][7fea5156c200] nsDragSession::nsDragSession()
[Parent 167077: Main Thread]: D/WidgetDrag [D 0][7fea5156c200] nsDragSession::InvokeDragSession
[Parent 167077: Main Thread]: D/WidgetDrag [D 0][7fea5156c200] nsDragSession::InvokeDragSessionImpl
[Parent 167077: Main Thread]: D/WidgetDrag [D 0][7fea5156c200]   numDragItems = 1
[Parent 167077: Main Thread]: D/WidgetDrag adding target application/x-moz-tabbrowser-tab
[Parent 167077: Main Thread]: D/WidgetDrag adding target text/x-moz-text-internal
[Parent 167077: Main Thread]: D/WidgetDrag invisibleSourceDragBegin (7fea55fdfb30)
[Parent 167077: Main Thread]: D/WidgetDrag [D 0][7fea5156c200] nsDragSession::SourceBeginDrag(7fea55fdfb30)
[Parent 167077: Main Thread]: D/WidgetDrag [D 0][7fea5156c200] nsDragSession::SetDragIcon(7fea55fdfb30)
[Parent 167077: Main Thread]: D/WidgetDrag [D 0][7fea5156c200]   set drag popup [7fea4c4e1400]
[Parent 167077: Main Thread]: D/WidgetDrag [D 0][7fea5156c200]   GdkDragContext [7fea55fdfb30] nsWindow [7fea83313800]

[Parent 167077: Main Thread]: D/WidgetDrag mShell::drag_motion
[Parent 167077: Main Thread]: D/WidgetDrag WindowDragMotionHandler target nsWindow [7fea83313800]
[Parent 167077: Main Thread]: D/WidgetDrag WindowDropPosition [110, 212]
[Parent 167077: Main Thread]: D/WidgetDrag [D 1][7fea5156c200] nsDragSession::Schedule(7fea89042710) task eDragTaskMotion window 7fea83313800
[Parent 167077: Main Thread]: D/WidgetDrag [D 1][7fea5156c200] nsDragSession::UpdateDragAction(7fea89042710)

broken one:

[Parent 166383: Main Thread]: D/WidgetDrag [D 0][7f22d31c5d00] nsDragSession::nsDragSession()
[Parent 166383: Main Thread]: D/WidgetDrag [D 0][7f22d31c5d00] nsDragSession::InvokeDragSession
[Parent 166383: Main Thread]: D/WidgetDrag [D 0][7f22d31c5d00] nsDragSession::InvokeDragSessionImpl
[Parent 166383: Main Thread]: D/WidgetDrag [D 0][7f22d31c5d00]   numDragItems = 1
[Parent 166383: Main Thread]: D/WidgetDrag adding target application/x-moz-tabbrowser-tab
[Parent 166383: Main Thread]: D/WidgetDrag adding target text/x-moz-text-internal
[Parent 166383: Main Thread]: D/WidgetDrag invisibleSourceDragBegin (7f22e56c9df0)
[Parent 166383: Main Thread]: D/WidgetDrag [D 0][7f22d31c5d00] nsDragSession::SourceBeginDrag(7f22e56c9df0)
[Parent 166383: Main Thread]: D/WidgetDrag [D 0][7f22d31c5d00] nsDragSession::SetDragIcon(7f22e56c9df0)
[Parent 166383: Main Thread]: D/WidgetDrag [D 0][7f22d31c5d00]   set drag popup [7f22e5d35800]
[Parent 166383: Main Thread]: D/WidgetDrag [D 0][7f22d31c5d00]   GdkDragContext [7f22e56c9df0] nsWindow [7f2316619e00]

[Parent 166383: Main Thread]: D/Widget [7f2316619e00]: Button 1 release

so D&D is terminated before we get first drag_motion event - looks like D&D doesn't actually start.

Comment 23

[Martin Stránský [:stransky] (ni? me) (PTO till June 6)]

Looks like invisibleSourceDragBegin() is called but we don't get anything else. Anyway, looks like Wayland backend bug.

Comment 24

[Martin Stránský [:stransky] (ni? me) (PTO till June 6)]

So it's good old https://gitlab.gnome.org/GNOME/mutter/-/issues/740 one.

Comment 25

[Sarah Clements [:sclements]]

Thanks for looking into this Martin. So with it being a known backend/OS issue, there probably isn't any real workaround us frontend folks would be able to implement?

Comment 26

[Sarah Clements [:sclements]]

Although, with this being a known issue then it probably wasn't regressed by Nikki's patch - just made more obvious by it?

Comment 27

[Martin Stránský [:stransky] (ni? me) (PTO till June 6)]

Attachment: Bug 1979719 [Wayland] Terminate D&D operation if we don't get motion event before button release r?emilio

Comment 28

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/929176c19fb9
https://hg.mozilla.org/integration/autoland/rev/3bfe8b55ca45
[Wayland] Terminate D&D operation if we don't get motion event before button release r=emilio

Comment 29

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/dbd43bc84e1d
https://hg.mozilla.org/integration/autoland/rev/22d5d58daf09
Revert "Bug 1979719 [Wayland] Terminate D&D operation if we don't get motion event before button release r=emilio" for causing build bustages at nsWindow.cpp

Comment 30

[[e-mail]]

Backed out for causing build bustages at nsWindow.cpp

- Backout link
- Push with failures
- Failure log
Failure line: /builds/worker/checkouts/gecko/widget/gtk/nsWindow.cpp:8189:5: error: functions marked as MOZ_CAN_RUN_SCRIPT can only be called from functions also marked as MOZ_CAN_RUN_SCRIPT

Comment 31

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/89a4f8a9d316
https://hg.mozilla.org/integration/autoland/rev/8571c0889b73
[Wayland] Terminate D&D operation if we don't get motion event before button release r=emilio

Comment 32

[Serban Stanca [:SerbanS]]

https://hg.mozilla.org/mozilla-central/rev/8571c0889b73

Comment 33

[Ryan VanderMeulen [:RyanVM]]

Did you want to nominate this for ESR140 uplift? It cherry-picks cleanly.

Comment 34

[Martin Stránský [:stransky] (ni? me) (PTO till June 6)]

Comment on attachment 9505548 [details]
Bug 1979719 [Wayland] Terminate D&D operation if we don't get motion event before button release r?emilio

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: Better Wayland workaround handling, saves extra user mouse click to left broken/unfinished D&D operation under Wayland.
• User impact if declined:
• Fix Landed on Version:
• Risk to taking this patch: Medium
• Why is the change risky/not risky? (and alternatives if risky): Medium risk, we change mouse event handling a bit to catch unfinished D&D earlier, after first mouse button release after D&D start.

Comment 35

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9505548 [details]
Bug 1979719 [Wayland] Terminate D&D operation if we don't get motion event before button release r?emilio

Approved for 140.3esr.

Comment 36

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-esr140/rev/453460cf0f47

Comment 37

[Raluca Popovici, Desktop QA]

I was able to reproduce this issue in the older Nightly build 143.0a1 (2025-07-28) on Ubuntu 24.10 with Wayland.
Verified as fixed on Fx 143.0, ESR 140.3.0, and Nightly 144.0a1 (2025-09-09) on Ubuntu 24.10 with Wayland.