2022238 - [Wayland] Toolbar stops responding to clicks

Status: RESOLVED FIXED

(Core :: Widget: Gtk, defect)

Description

[Nicolò Ribaudo]

Attachment: about:support

Frequently (every 1-2 hours) the browser "toolbar" (the one that contains the back/forward buttons, the address bar, the extensions, and the menu button) stops responding to clicks. It is not frozen: if I for example navigate back&forth with keyboard shortcuts, I see the arrow in the toolbar updating their state. The tabs above the toolbar work partially: I can click on them to switch to a tab, but I cannot drag to reorder them.

This is likely Wayland-specific, as I was on X11 until a few days ago and I only started seeing this bug once I switched.

Is there any way I can help debugging this? The browser UI is in JS, right? Can I open devtools on it?

Comment 1

[BugBot [:suhaib / :marco]]

The Bugbug bot thinks this bug should belong to the 'Core::Widget: Gtk' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Nicolò Ribaudo]

Ok I got the devtools on the browser UI to work.

If I manually call reloadButton.click() it works.

If I add a event listener logpoint for "click", when clicking on the button it logs [see attached image].

Comment 3

[Nicolò Ribaudo]

Attachment: logs_on_click.png

Comment 4

[Nicolò Ribaudo]

It seems like when this bug is happening, clicking anywhere in the toolbar fires an event whose .target is the whole toolbox (<toolbox id="navigator-toolbox" movingtab>) rather than the specific thing I'm clicking on.

Comment 5

[Nicolò Ribaudo]

Oh and when the bug is happening, the "Pick an element" think in the devtools only allows me to pick either the tabs or the whole top bar, and it does not let me pick the individual elements within the toolbar.

Comment 6

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

Can you please run on terminal with MOZ_LOG="WidgetDrag:5" and attach the log here when it happens? Run for instance as:

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

and attach log.txt file here.
Thanks.

Comment 7

[Nicolò Ribaudo]

These are the logs from when I started the browser to when I tried interacting with the toolbar and it was not receiving clicks (at 10:57). I had started the browser at around 10:35.

➜ MOZ_LOG="WidgetDrag:5" firefox-nightly 2>&1 | ts '[%Y-%m-%d %H:%M:%S]' | tee firefox-log.txt
[2026-03-11 10:55:15] [Parent 462649: Main Thread]: D/WidgetDrag [D 0][708422c5ef00] nsDragSession::nsDragSession()
[2026-03-11 10:55:15] [Parent 462649: Main Thread]: D/WidgetDrag [D 0][708422c5ef00] nsDragSession::InvokeDragSession
[2026-03-11 10:55:15] [Parent 462649: Main Thread]: D/WidgetDrag [D 0][708422c5ef00]   numDragItems = 1
[2026-03-11 10:55:15] [Parent 462649: Main Thread]: D/WidgetDrag adding target application/x-moz-tabbrowser-tab
[2026-03-11 10:55:15] [Parent 462649: Main Thread]: D/WidgetDrag adding target text/x-moz-text-internal
[2026-03-11 10:55:15] [Parent 462649: Main Thread]: D/WidgetDrag [D 0][708422c5ef00] nsDragSession::InvokeDragSessionImpl() originGdkWindow [70843cd59240]
[2026-03-11 10:55:15] [Parent 462649: Main Thread]: D/WidgetDrag invisibleSourceDragBegin (70842d3ef710)
[2026-03-11 10:55:15] [Parent 462649: Main Thread]: D/WidgetDrag [D 0][708422c5ef00] nsDragSession::SourceBeginDrag(70842d3ef710)
[2026-03-11 10:55:15] [Parent 462649: Main Thread]: D/WidgetDrag [D 0][708422c5ef00] nsDragSession::SetDragIcon(70842d3ef710)
[2026-03-11 10:55:15] [Parent 462649: Main Thread]: D/WidgetDrag [D 0][708422c5ef00]   set drag popup [7084295df700]
[2026-03-11 10:55:15] [Parent 462649: Main Thread]: D/WidgetDrag [D 0][708422c5ef00]   GdkDragContext [70842d3ef710] nsWindow [70844882e300]

Comment 8

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

Nicolò, is the log complete? Looks like D&D has started but it's still running - we didn't get any D&D termination.
Please try again and attach complete log.
Thanks.

Comment 9

[Nicolò Ribaudo]

Yes, that whose the whole log. I actually run it twice, because after the first time I thought I had the wrong env flag set given how little it logged, and both times it was similar.

In other news, I have been running firefox with logging enabled since yesterday and the bug didn't happen yet. Before it was happening multiple times per day, so maybe something fixed it?

I'll keep running firefox with logs for a week, if I get nothing useful I'll close this.

Comment 10

[Alice0775 White]

Duplication of Bug 2020110?

Comment 11

[Stephen Thompson [:sthompson]]

:decoder reported the same issue with the same presentation (#tabbrowser-tabs element has movingtab attribute and style attributes that mean the tab strip drag-drop front-end code did not terminate properly). Ubuntu on Wayland with Nightly 150 of March 18. That suggests that the mitigations from bug 2020110 are not sufficient to resolve this problem. However, based on Nicoló Ribaudo's reports in comment 9, perhaps the mitigations did make it less likely for improper drag operation termination to block elements on the front end...?

Comment 12

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

I think we just need to revert Bug 2001075 and implement a custom D&D handler.

Comment 13

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

Attachment: Bug 2022238 [Wayland] Revert Bug 2001075 to avoid toolbar freeze r?emilio

Comment 14

[Nicolò Ribaudo]

It seems like the mitigations in https://bugzilla.mozilla.org/show_bug.cgi?id=2020110 have been pushed 8 days ago, and I investigated this issue 9 days ago. As in the past few days I have not been able to reproduce this anymore, maybe it's actually fully fixed by https://github.com/mozilla-firefox/firefox/commit/f5b943ce88ae?

Comment 15

[BugBot [:suhaib / :marco]]

Set release status flags based on info from the regressing bug 2001075

Comment 16

[Nicolò Ribaudo]

Oh well, it just happened again. The log looks similar to last time:

[2026-03-20 15:26:11] [Parent 547803: Main Thread]: D/WidgetDrag [D 0][73feeb378400] nsDragSession::nsDragSession()
[2026-03-20 15:26:11] [Parent 547803: Main Thread]: D/WidgetDrag [D 0][73feeb378400] nsDragSession::InvokeDragSession
[2026-03-20 15:26:11] [Parent 547803: Main Thread]: D/WidgetDrag [D 0][73feeb378400]   numDragItems = 1
[2026-03-20 15:26:11] [Parent 547803: Main Thread]: D/WidgetDrag adding target application/x-moz-tabbrowser-tab
[2026-03-20 15:26:11] [Parent 547803: Main Thread]: D/WidgetDrag adding target text/x-moz-text-internal
[2026-03-20 15:26:11] [Parent 547803: Main Thread]: D/WidgetDrag [D 0][73feeb378400] nsDragSession::InvokeDragSessionImpl() originGdkWindow [73ff467bda60]
[2026-03-20 15:26:11] [Parent 547803: Main Thread]: D/WidgetDrag invisibleSourceDragBegin (73ff5bdce0e0)
[2026-03-20 15:26:11] [Parent 547803: Main Thread]: D/WidgetDrag [D 0][73feeb378400] nsDragSession::SourceBeginDrag(73ff5bdce0e0)
[2026-03-20 15:26:11] [Parent 547803: Main Thread]: D/WidgetDrag [D 0][73feeb378400] nsDragSession::SetDragIcon(73ff5bdce0e0)
[2026-03-20 15:26:11] [Parent 547803: Main Thread]: D/WidgetDrag [D 0][73feeb378400]   set drag popup [73feade3c600]
[2026-03-20 15:26:11] [Parent 547803: Main Thread]: D/WidgetDrag [D 0][73feeb378400]   GdkDragContext [73ff5bdce0e0] nsWindow [73ff261ceb00]

It seems however like I am still on an older version of nightly (150.0a1 (2026-03-05)), which is the latest I'm getting from Mozilla's apt repository

Comment 17

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

Bug 2020110 was reverted due to regressions.

Comment 21

[Daniel Bodea [:danibodea]]

I've attempted to reproduce this issue on Ubuntu 24.04.4 LTS with Wayland window protocol on both x64 and aarch64 architectures using Nightly v150.0a1 ID:20260305093321. I've created some user data to simulate a normal user experience (passwords, logins, addons, large amounts of cache, etc.) and I've navigated websites randomly on 2 different systems for hours, but none of the described simptoms were observed (unresponsiveness, console errors...). This issue appears to have some special reproduction steps or to be specific to some hardware/drivers.

While analyzing the latest comments, it would appear that this bug was not regressed by bug 2020110 because it landed in 2026-03-11 and this report was logged in 2026-02-27.

From potential duplicate bug 2008880, it would appear that the issue is reproducible in Throubleshoot mode, meaning that is might not be caused by addons/user data.

I will attempt to bring some value to this report by providing a series of questions for the reporter:
@Nicolò Ribaudo: Would you answer some of our questions in the hope of finding the cause of your bug?

1. Is there a specific action that you perform right before the issue reproduces?
   (like dragging a tab or other elements?; anything that comes to mind...)
2. Which actions do you perform in the browser most often?
3. Does this issue still reproduce in the latest Nightly (like Nightly v150.0a1 from 2026-03-23?)
4. Did it reproduce in the last days? which builds did you use? Was it more recent than 2026-03-05 (as shown in about:support info)?
5. Can you describe exactly how you install the build?
   Thank yuo for your help!

Comment 22

[Stephen Thompson [:sthompson]]

Based on some discussions in the #firefox channel, some users have run into this issue but do not necessarily remember dragging tabs. However, it is possible that a user just clicking on a tab to select it may cause the drag-drop code to run because the mouse was moving slightly during the click. In this scenario, the tabs will not actually move because the "drag" was over a very short distance, but the Firefox front-end would still set the "movingtab" attribute on the tab strip and make the horizontal tab strip cover up elements below it https://searchfox.org/firefox-main/rev/7b74d86ca4ce65e82fdaa3095d2d39a26d3ac4f6/browser/themes/shared/tabbrowser/tabs.css#150-154 If the Firefox front-end does not receive a message that the "drag" operation was terminated, then the tab strip would remain covering up the toolbar, URL bar, etc. and make those inaccessible by the mouse.

Comment 23

[:gerard-majax]

(In reply to Stephen Thompson [:sthompson] from comment #22)

Based on some discussions in the #firefox channel, some users have run into this issue but do not necessarily remember dragging tabs. However, it is possible that a user just clicking on a tab to select it may cause the drag-drop code to run because the mouse was moving slightly during the click. In this scenario, the tabs will not actually move because the "drag" was over a very short distance, but the Firefox front-end would still set the "movingtab" attribute on the tab strip and make the horizontal tab strip cover up elements below it https://searchfox.org/firefox-main/rev/7b74d86ca4ce65e82fdaa3095d2d39a26d3ac4f6/browser/themes/shared/tabbrowser/tabs.css#150-154 If the Firefox front-end does not receive a message that the "drag" operation was terminated, then the tab strip would remain covering up the toolbar, URL bar, etc. and make those inaccessible by the mouse.

I think it captures very well the way it behaves recently ; I've been hitting this for a couple of weeks / months after a period of stability, and most of the time the pattern I can see is that at some point in the future after locking the state ; I see a new tab being opened in a new window, and this tab is one of my pinned icons.

Comment 24

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

I see that when tabs are switched but the mouse button is not released immediately while mouse cursor is moving so D&D is started and terminated quickly and there's the blockage then.

Comment 25

[Christian Holler (:decoder)]

Here's a log I captured when it happened on my machine (long running Firefox):

[5:36 PM][2979974] Sandbox: CanCreateUserNamespace() unshare(CLONE_NEWPID): EPERM
libva info: VA-API version 1.20.0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so
libva info: Found init function __vaDriverInit_1_20
libva info: va_openDriver() returns 0
[fluent-dom] An element named "icon" wasn't found in the source.
[fluent-dom] An element named "icon" wasn't found in the source.
[Parent 2979972: Main Thread]: D/WidgetDrag [D 0][756c884b7800] nsDragSession::nsDragSession()
[Parent 2979972: Main Thread]: D/WidgetDrag [D 0][756c884b7800] nsDragSession::InvokeDragSession
[Parent 2979972: Main Thread]: D/WidgetDrag [D 0][756c884b7800]   numDragItems = 1
[Parent 2979972: Main Thread]: D/WidgetDrag adding target application/x-moz-tabbrowser-tab
[Parent 2979972: Main Thread]: D/WidgetDrag adding target text/x-moz-text-internal
[Parent 2979972: Main Thread]: D/WidgetDrag [D 0][756c884b7800] nsDragSession::InvokeDragSessionImpl() originGdkWindow [756f453be300]
[Parent 2979972: Main Thread]: D/WidgetDrag invisibleSourceDragBegin (756c3c3f6710)
[Parent 2979972: Main Thread]: D/WidgetDrag [D 0][756c884b7800] nsDragSession::SourceBeginDrag(756c3c3f6710)
[Parent 2979972: Main Thread]: D/WidgetDrag [D 0][756c884b7800] nsDragSession::SetDragIcon(756c3c3f6710)
[Parent 2979972: Main Thread]: D/WidgetDrag [D 0][756c884b7800]   set drag popup [756ed31d5f00]
[Parent 2979972: Main Thread]: D/WidgetDrag [D 0][756c884b7800]   GdkDragContext [756c3c3f6710] nsWindow [756f45377d00]
[Parent 2979972: Main Thread]: D/WidgetDrag nsWindow::OnUnmap() Drag cancel
[Parent 2979972: Main Thread]: D/WidgetDrag invisibleSourceDragFailed(756c3c3f6710) GTK_DRAG_RESULT_NO_TARGET
[Parent 2979972: Main Thread]: D/WidgetDrag [D 0][756c884b7800] SourceEndDragSession(756c3c3f6710) result GTK_DRAG_RESULT_NO_TARGET
[Parent 2979972: Main Thread]: D/WidgetDrag [D 0][756c884b7800]   guess drag end point 3758 18
[Parent 2979972: Main Thread]: D/WidgetDrag [D 0][756c884b7800]   drop action is none
[Parent 2979972: Main Thread]: D/WidgetDrag [D 0][756c884b7800] nsDragSession::Schedule(0) task eDragTaskSourceEnd window 0
[Parent 2979972: Main Thread]: D/WidgetDrag invisibleSourceDragEnd(756c3c3f6710)
[Parent 2979972: Main Thread]: D/WidgetDrag [D 0][756c884b7800] SourceEndDragSession(756c3c3f6710) result GTK_DRAG_RESULT_SUCCESS
[Parent 2979972: Main Thread]: D/WidgetDrag [D 1][756c884b7800] nsDragSession::RunScheduledTask() task eDragTaskSourceEnd mTargetWindow 0 mPendingWindow 0
[Parent 2979972: Main Thread]: D/WidgetDrag [D 1][756c884b7800]   quit, selected task eDragTaskSourceEnd
[Parent 2979972: Main Thread]: D/WidgetDrag [D 1][756c884b7800] nsDragSession::EndDragSessionImpl(0) 1
[Parent 2979972: Main Thread]: D/WidgetDrag [D 0][756c884b7800] nsDragSession::~nsDragSession
[Parent 2979972: Main Thread]: D/WidgetDrag [D 0][756c884b7800] nsDragSession::RemoveTempFiles

Comment 26

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/361b4916dba1
https://hg.mozilla.org/integration/autoland/rev/b40d829ebaf8
[Wayland] Revert Bug 2001075 to avoid toolbar freeze r=emilio

Comment 27

[pstanciu]

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

Comment 28

[Pascal Chevrel (relman team) -> :pascalc]

Should we uplift that revert to beta (and release) end of week or do we want to let bake on nightly for a few days first?

Comment 29

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

(In reply to Pascal Chevrel:pascalc from comment #28)

Should we uplift that revert to beta (and release) end of week or do we want to let bake on nightly for a few days first?

Uplift is the best option, we don't need to test that as it's what we have before there.

Comment 30

[BugBot [:suhaib / :marco]]

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.
  • See https://wiki.mozilla.org/Release_Management/Requesting_an_Uplift for documentation on how to request an uplift.
• If no, please set status-firefox150 to wontfix.

For more information, please visit BugBot documentation.

Comment 31

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

Attachment: Bug 2022238 [Wayland] Revert Bug 2001075 to avoid toolbar freeze

Original Revision: https://phabricator.services.mozilla.com/D288856

Comment 32

[Phabricator Automation]

firefox-beta Uplift Approval Request

• User impact if declined/Reason for urgency: Inactive toolbar/url bar after D&D on Wayland.
• Code covered by automated testing?: no
• Fix verified in Nightly?: no
• Needs manual QE testing?: no
• Steps to reproduce for manual QE testing:
• Risk associated with taking this patch: low
• Explanation of risk level: Low - we revert Bug 2001075 - and use what we have before. Affects how we handle wayland D&D errors.
• String changes made/needed?: no
• Is Android affected?: no

Comment 33

[Pulsebot]

https://github.com/mozilla-firefox/firefox/commit/13782f63f1a0
https://hg.mozilla.org/releases/mozilla-beta/rev/af52719301e7

Comment 35

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

Attachment: Bug 2022238 [Wayland] Revert Bug 2001075 to avoid toolbar freeze a=diannaS

Original Revision: https://phabricator.services.mozilla.com/D288856

Comment 36

[Phabricator Automation]

firefox-release Uplift Approval Request

• User impact if declined/Reason for urgency: Broken D&D on Linux/Wayland, getting more dupes from 149.0
• Code covered by automated testing?: no
• Fix verified in Nightly?: no
• Needs manual QE testing?: no
• Steps to reproduce for manual QE testing:
• Risk associated with taking this patch: low
• Explanation of risk level: Revert previous commit, remove D&D workaround.
• String changes made/needed?: none
• Is Android affected?: no

Comment 37

[Pulsebot]

https://github.com/mozilla-firefox/firefox/commit/224d0b1fa2b3
https://hg.mozilla.org/releases/mozilla-release/rev/f72b94568da3

Comment 40

[Josh Aas]

I have this exact same problem in Firefox 149.0.2 for macOS.

Comment 41

[Stephen Thompson [:sthompson]]

Hi Josh Aas,

Thank you for the report. I filed bug 2033014 to account for your problem because it likely has a different root cause than this bug, which only affects Linux machines running Wayland.

If you still have the affected browser window open, could you open the browser toolbox and do either of the following?:

1. inspect the element with ID tabbrowser-tabs and check whether it has the attribute movingtab
2. run document.getElementById("tabbrowser-tabs").hasAttribute("movingtab") in the browser console

If either of those is the case, that will help us identify whether the toolbar interaction problems were caused by drag-drop misbehavior or some other cause.