Cannot use Drag and Drop in gnome-shell 42 (Wayland session)

Daniel, could you check on this one?

Status changed to 'Confirmed' because the bug affects multiple users.

Confirmed tabs can't be dragged in FF 98 on Wayland. But FF 97 (deb) in the same Wayland session works fine. Seems like a regression that's new in FF 98 although it might relate to an older issue: https://bugzilla.mozilla.org/show_bug.cgi?id=1700591

The tarball of the same release works just fine:

https://download-installer.cdn.mozilla.net/pub/firefox/releases/98.0.1/linux-x86_64/en-US/firefox-98.0.1.tar.bz2

So this seems to be a snap-only (confinement?) bug.

Maybe it's simpler than that.

When it's working, about:support reports:

  Window Protocol = xwayland

and when it's failing you see:

  Window Protocol = wayland

Firefox 97.0.1 (deb) reports it is using "wayland" in about:support, and tabs can be dragged just fine.

Firefox 98.0.1 (tar) when run with MOZ_ENABLE_WAYLAND=1, reports it is using "wayland" in about:support and tabs can be dragged just fine.

So it only fails in Firefox snaps that use native Wayland.

Same bug in the 91.7.1esr-2 snap.

Possibly related:

https://bugzilla.mozilla.org/show_bug.cgi?id=1739339
https://bugzilla.mozilla.org/show_bug.cgi?id=1700591

Weird. No bug in Weston with the same firefox 98.0.1-2 snap that fails in GNOME.

Is it perhaps related to the fix for bug 1959596?

The same Firefox snap doesn't start at all in Xorg sessions. Seems Firefox lost the ability to connect to X11 display :0 when all other X11 apps still can. --> bug 1965113

This appears to be a snap-specific problem, indeed.

I do occasionally get crashes when attempting to rearrange tabs as well. The crashes happen both in .deb & snap versions of firefox though?

It looks like any kind of drag and drop doesn't work in the snap version of Firefox under Wayland session.
First I've noticed that I couldn't personalize the toolbar, therefore I've open this bug report: https://bugzilla.mozilla.org/show_bug.cgi?id=1760449
Then I realized also tabs couldn't be moved.

Presumably drag-and-drop involves some IPC so that would be what is getting blocked in the snap version.

When running with MOZ_LOG=WidgetDrag:5 in jammy, this is what I'm seeing when I drag a tab:

[Parent 82683: Main Thread]: D/WidgetDrag nsDragService::InvokeDragSession
[Parent 82683: Main Thread]: D/WidgetDrag adding target application/x-moz-tabbrowser-tab
[Parent 82683: Main Thread]: D/WidgetDrag adding target text/x-moz-text-internal
[Parent 82683: Main Thread]: D/WidgetDrag invisibleSourceDragBegin
[Parent 82683: Main Thread]: D/WidgetDrag nsDragService::SetDragIcon()
[Parent 82683: Main Thread]: D/WidgetDrag set drag popup [7fe9ee004000]
[Parent 82683: Main Thread]: D/WidgetDrag nsDragService::StartDragSession
[Parent 82683: Main Thread]: D/WidgetDrag nsDragService::EndDragSession 0

The same action with the same version of the snap in impish is successful, and has a lot more logs:

[Parent 2923: Main Thread]: D/WidgetDrag nsDragService::InvokeDragSession
[Parent 2923: Main Thread]: D/WidgetDrag adding target application/x-moz-tabbrowser-tab
[Parent 2923: Main Thread]: D/WidgetDrag adding target text/x-moz-text-internal
[Parent 2923: Main Thread]: D/WidgetDrag invisibleSourceDragBegin
[Parent 2923: Main Thread]: D/WidgetDrag nsDragService::SetDragIcon()
[Parent 2923: Main Thread]: D/WidgetDrag set drag popup [7f944ac8dc00]
[Parent 2923: Main Thread]: D/WidgetDrag nsDragService::StartDragSession
[Parent 2923: Main Thread]: D/WidgetDrag WindowDragMotionHandler nsWindow 7f9467fd3400 coords [74, 11]
[Parent 2923: Main Thread]: D/WidgetDrag nsDragService::Schedule() task eDragTaskMotion window 7f9467fd3400
[Parent 2923: Main Thread]: D/WidgetDrag nsDragService::RunScheduledTask() task eDragTaskMotion mTargetWindow 0 mPendingWindow 7f9467fd3400
[Parent 2923: Main Thread]: D/WidgetDrag nsDragService::StartDragSession
[Parent 2923: Main Thread]: D/WidgetDrag start drag session mTargetWindow 7f9467fd3400 mTargetWidget 7f946abd2760
[Parent 2923: Main Thread]: D/WidgetDrag process motion event
[Parent 2923: Main Thread]: D/WidgetDrag nsDragService::UpdateDragAction()
[Parent 2923: Main Thread]: D/WidgetDrag nsDragService::SetCanDrop 1
[Parent 2923: Main Thread]: D/WidgetDrag nsDragService::ReplyToDragMotion can drop 1
[Parent 2923: Main Thread]: D/WidgetDrag gdk_drag_status() action 4
[Parent 2923: Main Thread]: D/WidgetDrag clear mTargetWindow mTargetWidget and other data
[Parent 2923: Main Thread]: D/WidgetDrag remove task source
[Parent 2923: Main Thread]: D/WidgetDrag WindowDragMotionHandler nsWindow 7f9467fd3400 coords [55, 11]
[Parent 2923: Main Thread]: D/WidgetDrag nsDragService::Schedule() task eDragTaskMotion window 7f9467fd3400
[Parent 2923: Main Thread]: D/WidgetDrag nsDragService::RunScheduledTask() task eDragTaskMotion mTargetWindow 7f9467fd3400 mPendingWindow 7f9467fd3400
[Parent 2923: Main Thread]: D/WidgetDrag nsDragService::StartDragSession
[Parent 2923: Main Thread]: D/WidgetDrag start drag session mTargetWindow 7f9467fd3400 mTargetWidget 7f946abd2760
[Parent 2923: Main Thread]: D/WidgetDrag process motion event
[Parent 2923: Main Thread]: D/WidgetDrag nsDragService::UpdateDragAction()
[Parent 2923: Main Thread]: D/WidgetDrag nsDragService::SetCanDrop 1
[Parent 2923: Main Thread]: D/WidgetDrag nsDragService::Repl...

Some notes on what I have tested so far:

 - the firefox flatpak isn't affected

 - running directly the firefox binary from the snap, unconfined (without snapd mediation) doesn't exhibit the problem

 - I incrementally upgraded components in an impish VM (where the problem isn't observed), getting them from jammy:
   - wayland 1.20.0, still works
   - mutter 41.3-1ubuntu1 (along with libglib2.0 2.70.0, gnome-keyring 40.0, libgcrypt20 1.9.4), still works
   - mutter 42~beta (along with libc6 2.35, pipewire 0.3.38, libinput 1.19.3, libwacom 2.0.0), still works
   - gnome-shell 41.3 (along with gjs 1.71.1, mozjs91 91.7.0, icu 70.1, gsettings-desktop-schemas 41.0), still works
   - gnome-shell 42~beta (along with libadwaita 1.1.0, gsettings-desktop-schemas 42.0, gtk4 4.6.2, pango1.0 1.50.4, yaru-theme 22.04.3), breaks

So the regression seems to be evidenced when upgrading gnome-shell from 41.3 to 42~beta. I took a look at the diff, but it's quite large and I couldn't spot anything obvious.
On a hunch, I reverted the new screenshot UI in gnome-shell 42 (rebuilt packages locally), but it didn't make a difference.

Take in mind that upgrading the shell you're also using libmutter-10 instead of libmutter-9, so the problem may be anywhere in both (more likely in mutter).

So the only way to find out what may have changed this is using git bisect over the various mutter versions (might be annoying, because you need to keep shell in sync with that).

If the unconfined snap isn't affected, could be that mutter is now using something that is blocked by the confinement?

I attempted to bisect mutter for this but could not get the firefox snap binaries to run at all in my development builds. Missing some environment created by a proper login I guess, so what environment is required for snaps?

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:
http://iso.qa.ubuntu.com/qatracker/reports/bugs/1964541

From https://forum.snapcraft.io/t/firefox-pinch-to-zoom-not-working-on-22-04/29391, another symptom is pinch-to-zoom not working in the firefox snap under wayland in jammy. Which suggests the problem is more general than just drag-and-drop.

It's not just firefox: I just tested the gedit snap on impish and jammy. While dragging tabs to re-order them seems to work in both releases, dragging a selected chunk of text to move it around in the editor works in impish but not in jammy.

See also https://bugzilla.mozilla.org/show_bug.cgi?id=1710344

I rebuilt and installed mutter and gnome-shell 41.5 in jammy, and drag and drop works there, so it really is a regression in the 42 branch.

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;
         }

Upstream issue is https://gitlab.gnome.org/GNOME/mutter/-/issues/2216

Proposed fix: https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2368

So... Per sé the issue only affect apps that are bundled / static linked with old Gdk version, while there may be many around in snaps and flatpaks, I think it's better to workaround the issue at mutter level too, so we'll handle both there and in the platform snap.

Problem solved with firefox 99.0.1-1 1232

No I don't think so...

FAIL: 99.0-2 (1188)
FAIL: 100.0b5-1 (1236)

Doesn't matter though, because a proper fix is coming in mutter.

Corrado is right, but that's a side effect of disabling native wayland support in the firefox snap, thus having it use xwayland, rather than an actual fix to the root cause of the problem. But as Daniel is pointing out, a proper fix is coming.

Note that only the stable channel has been reverted to xwayland, the firefox snap in beta and edge will still do wayland natively.

I hope we get back to Firefox with Wayland enabled soon because the performance difference was noticeable last time I checked.

Yes, that's definitely the intention. Mozilla was concerned that they didn't have automated testing in place to catch bugs and regressions in a timely manner, hence the temporary revert. See https://bugzilla.mozilla.org/show_bug.cgi?id=1725245 for more details.

This bug was fixed in the package mutter - 42.0-3ubuntu1

---------------
mutter (42.0-3ubuntu1) jammy; urgency=medium

  [ Marco Trevisan (Treviño) ]
  * debian/patches: Cherry-pick various upstream commits for 42.1:
    + onscreen/native: Fall back if COPY_MODE_SECONDARY_GPU fails to init
      (LP: #1964037, #1959888)
  * debian/patches: Allow any drag timestamp as drag start serial (LP: #1964541)
  * debian/patches: Move x11-fractional scaling under ubuntu namespace
  * debian/patches: Account ClutterStage grabs on Wayland key focus sync
    (LP: #1964442)
  * debian/libmutter-10-0.symbols: Update including new internal symbols
  * debian/patches: Avoid memory errors when comparing gamma values
  * debian/patches: Fix privacy-screen and connectors updates with
    triple-buffering (LP: #1966178)
  * debian/patches: Ensure privacy screen settings are applied on startup
    (LP: #1966178)

  [ Jeremy Bicha ]
  * Merge from Debian unstable. Remaining changes:
    - debian/patches/x11-Add-support-for-fractional-scaling-using-Randr.patch:
      + X11: Add support for fractional scaling using Randr
    - Add triple-buffering patch
    - debian/libmutter-10-0.symbols: Add symbols for triple buffering patch
    - ubuntu/wayland-data-device-Allow-any-drag-timestamp-as-drag-star.patch:
      + handle DnD for old (snapped) gtk apps that used wrong wayland serials

mutter (42.0-3) unstable; urgency=medium

  [ Marco Trevisan (Treviño) ]
  * debian/patches: Cherry-pick upstream fixes targeting 42.1
  * debian/patches: Ensure repick happens on actors visibility changed
    (LP: #1964545)

  [ Jeremy Bicha ]
  * Release to unstable

 -- Marco Trevisan (Treviño) <email address hidden> Wed, 13 Apr 2022 03:30:39 +0200

> I hope we get back to Firefox with Wayland enabled soon because the performance difference was noticeable last time I checked.

Plus, rendering of the entire Firefox window got blurry with fractional scaling. (Just to add one more reason :-) )

is there a way for users to re-enable wayland / override the DISABLE_WAYLAND=1 setting recently set in the snap?

The bug is now fixed in mutter, so to get back full performance of Firefox-on-Wayland you can do this:

  sudo snap remove firefox
  sudo snap install --beta firefox

Just a temporary workaround until the stable channel returns to native Wayland.

I think the stable channel will stay on Xwayland for a while, as mozilla wants to fully test what they ship as default and they're not doing it in wayland right now.

So, maybe Olivier, could you maybe move `DISABLE_WAYLAND` thingy in the firefox launcher so that if `MOZ_ENABLE_WAYLAND` is set then `DISABLE_WAYLAND` is not?

It would allow users to use the stable channel with wayland backend in case they explicitly requested it.

Sounds like Mozilla is doing the right thing, just the timing is inconvenient for jammy.

It doesn't hurt live sessions because those are Xorg anyway. But after you install, if Firefox is still using Xwayland for Wayland sessions then you will see Firefox has:

  * Slower frame rates
  * More laggy touchpad input
  * Blurry fractional scaling

I currently have the bug with Firefox 103.0b9 and mutter 42.2-0ubuntu1. It went away for a while then it came back; I was not able to determine the exact version which determined the (possible) regression. I am available for tests and any additional information if it can help. Thank you in advance for your time.

This bug is closed. To help us fully understand the remaining issue, please open a new bug.

I recall that drag and drop was known to be broken in Firefox on Wayland recently, which was one of the reasons it was reverted to use X11 instead (Xwayland).

AFAICT upstream preferred to fix this in GTK, and we already ship the GTK fix:

https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/4122

The fix is also in the gnome-3-38-2004 snap.