Closed Bug 1760449 Opened 4 years ago Closed 3 years ago

Toolbar/tabs drag & drop doesn't work - Firefox snap wayland

Categories

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

Firefox 98
Desktop
Linux
defect

Tracking

()

RESOLVED FIXED

People

(Reporter: jeremie.tamburini, Unassigned)

References

(Blocks 2 open bugs)

Details

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:98.0) Gecko/20100101 Firefox/98.0

Steps to reproduce:

Fresh installed Ubuntu 22.04 (still development version) with Firefox snap version 98.0.1
(Also tried version 99 and 100 available on https://snapcraft.io/firefox same behavior).

  1. Right click on toolbar
  2. Select "Customise Toolbar"
  3. Tried to remove items from the toolbar and add items on it via "drag and drop".

Actual results:

Nothing happens. It looks like drag and drop doesn't work.
While trying to move items, they simply disappear.
You can see a short video: https://www.youtube.com/watch?v=vsnr8O5EgFk

(Also tried to run Firefox from the terminal, but I didn't receive any warning while trying to customize the toolbar).

Expected results:

What should have happened is that every items should be moved between the toolbar and the list of items as shown in the official documentation:
https://support.mozilla.org/en-US/kb/customize-firefox-controls-buttons-and-toolbars

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

Component: Untriaged → Toolbars and Customization
OS: Unspecified → Linux
Hardware: Unspecified → Desktop

I've realized 2 new things:

  1. this problem is related to the Wayland session
  2. drag and drop doesn't work also with tabs

No problem at all selecting the xorg session at login, and this actually works as workaround.
I have seen other bug report mentioning similar problems. So my bug report could be a duplicated of 1739981 and 1739970

I'm going to update the first post.

Summary: Can't customize toolbar - Firefox snap → Toolbar/tabs drag & drop doesn't work - Firefox snap wayland
Component: Toolbars and Customization → Widget: Gtk
Product: Firefox → Core
Blocks: wayland, snap
Flags: needinfo?(jeremie.tamburini)
Priority: -- → P3

Thanks @Martin Stránský

I've run the test with Firefox nightly using the MOZ_ENABLE_WAYLAND=1 ./firefox -ProfileManager -no-remote parameters and everything works as expected.

The problem seems to be confined to snap version of Firefox in Wayland session (snap nightly version included). The snap package works fine with the old X11 session.

Flags: needinfo?(jeremie.tamburini)
See Also: → 1739339

Update from the launchpad bug:

I bisected mutter and gnome-shell until I identified the revision in mutter that caused the regression: https://gitlab.gnome.org/GNOME/mutter/-/commit/26676a829e74859488154cd8c45de1d0b629f3ca.

More specifically, the changes to src/core/events.c. Indeed I rebuilt mutter in jammy with the following patch, and the issue with the firefox snap was gone:

--- a/src/core/events.c
+++ b/src/core/events.c
@@ -523,10 +523,6 @@ meta_display_handle_event (MetaDisplay
 #ifdef HAVE_WAYLAND
   if (wayland_compositor && !bypass_wayland)
     {
-      if (window && event->type == CLUTTER_MOTION &&
-          event->any.time != CLUTTER_CURRENT_TIME)
-        meta_window_check_alive_on_event (window, event->any.time);
-
       if (meta_wayland_compositor_handle_event (wayland_compositor, event))
         bypass_clutter = TRUE;
     }

(In reply to Olivier Tilloy from comment #7)

Update from the launchpad bug:

I bisected mutter and gnome-shell until I identified the revision in mutter that caused the regression: https://gitlab.gnome.org/GNOME/mutter/-/commit/26676a829e74859488154cd8c45de1d0b629f3ca.

More specifically, the changes to src/core/events.c. Indeed I rebuilt mutter in jammy with the following patch, and the issue with the firefox snap was gone:

--- a/src/core/events.c
+++ b/src/core/events.c
@@ -523,10 +523,6 @@ meta_display_handle_event (MetaDisplay
 #ifdef HAVE_WAYLAND
   if (wayland_compositor && !bypass_wayland)
     {
-      if (window && event->type == CLUTTER_MOTION &&
-          event->any.time != CLUTTER_CURRENT_TIME)
-        meta_window_check_alive_on_event (window, event->any.time);
-
       if (meta_wayland_compositor_handle_event (wayland_compositor, event))
         bypass_clutter = TRUE;
     }

Do you have more context on this fix? I could use some assistance on how to implement it.

(In reply to jaz.zimms from comment #8)

Do you have more context on this fix? I could use some assistance on how to implement it.

There is nothing to implement: the issue is in gtk/mutter, and will be worked around/fixed there. See https://gitlab.gnome.org/GNOME/mutter/-/issues/2216 for details.

After testing locally, it looks like on a 22.04, nightly 103 snap (thus running wayland) I cannot repro. The upstream issue is still open, but maybe a workaround was landed in the distro. Do you still hit the issue ?

Flags: needinfo?(jeremie.tamburini)

Also wondering if you still hit it, since your comment suggest you did?

Flags: needinfo?(jaz.zimms)

Olivier, was a workaround landed and we could mark this as resolved?

Flags: needinfo?(olivier)

On my Ubuntu 22.10 problem is resolved for bot FF 101.0.1 snap and firefox-trunk: Installed: 103.0a1hg20220615r620926-0ubuntu0.22.10.1~umd1

Yes, a workaround was distro-patched into mutter 42.0-3ubuntu1 in Ubuntu 22.04 (see https://launchpad.net/bugs/1964541 for details).
So I think it is safe to mark this resolved.

Flags: needinfo?(olivier)
Status: UNCONFIRMED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Flags: needinfo?(jeremie.tamburini)
Flags: needinfo?(jaz.zimms)
You need to log in before you can comment on or make changes to this bug.