Closed Bug 1527976 Opened 5 years ago Closed 4 years ago

[Wayland] Dragging and dropping tab outside application windows does not create new window for tab

Categories

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

Product:
Core
Component:
Widget: Gtk
Version:
67 Branch
Platform:
x86_64
Linux
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla77
Tracking Flags:
Tracking Status
firefox76 --- fixed
firefox77 --- fixed

People

(Reporter: jhnmlkvch9, Assigned: stransky)

References

(Blocks 1 open bug)

Details

Attachments

(4 files, 1 obsolete file)

Bug 1527976 [Wayland] Don't cancel Drag and Drop on MOZ_GTK_DRAG_RESULT_ERROR for application/x-moz-tabbrowser-tab (tab move), r?jhorak
47 bytes, text/x-phabricator-request
RyanVM
: approval-mozilla-beta+
Details | Review
dd_problem_gentoo_20200427.webm
2.74 MB, video/webm
Details
ff76_moz_log_nsDragService5.log
17.90 KB, text/plain
Details
tab dragging succeeds only on first drag instance then consecutively fails
34.27 KB, text/plain
Details

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

Steps to reproduce:

  1. In a wayland compositor (weston for example) open Firefox nightly with GDK_BACKEND=wayland
  2. Open multiple tabs in a single browser window
  3. Now drag one tab out of the window

Actual results:

The dragged tab does not spawn a new firefox window with just that one tab.

Expected results:

A new firefox window should appear with just the one tab that had been dragged out of the parent window.

Component: Untriaged → Widget: Gtk
OS: Unspecified → Linux
Product: Firefox → Core
Hardware: Unspecified → x86_64

Dragging tabs within the bar to reorder doesn't do anything either. Did this regress recently, or am I misremembering?

If you can confirm that an old version still works, it would be very helpful if you could find the regression range.
https://mozilla.github.io/mozregression/quickstart.html

:stransky since you fixed bug 1463753, maybe you'd like to take a look at this when you get a chance.

Flags: needinfo?(stransky)

Dragging tabs within a window works fine for me on Sway.

Dragging tabs between different windows also works fine. The only case that does not work for me is the when a tab is dragged out of a window to spawn a new window.

The behavior i was seeing went away with the latest sway build, so it was either a problem with that sway build or otherwise transient, sorry for the noise. I can confirm that dragging to detach a tab is the only functionality not working.

The default D&D action depends on compositor. There are two available operations - copy and move - and depends on the compositor which one is the default. New window/tab rearrangement is triggered by "move" d&d operation. You may change the current action by CTRL/Shift modifiers.

Flags: needinfo?(stransky)

Jonny, can you try mutter (gnome shell) wayland compositor? Thanks.

Flags: needinfo?(jhnmlkvch9)

(In reply to Martin Stránský [:stransky] from comment #7)

Jonny, can you try mutter (gnome shell) wayland compositor? Thanks.

It now works in weston. Is this a new change since this report? It still does not work in Sway (rootston) even when I use the the modifiers (Ctrl/Shift).

If that works on weston/mutter it needs to be fixed on sway side.

Is this a dupe of Bug 1466444?

I also see this on Ubuntu 18.10 and holding Ctrl or Shift makes no difference.

Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Firefox Wayland drag + spawn tab → [Wayland] Dragging and dropping tab outside application windows does not create new window for tab
Priority: -- → P2

I can reproduce after while.

Flags: needinfo?(jhnmlkvch9)

I am also seeing this issue, consistently, on 68.0.1 running under sway w/ GDK_BACKEND=wayland set. It runs fine under xwayland.

This seems to be a GTK bug in Wayland implementation [1]:
When there's no consumer of the data the Xorg GTK implementation returns GDK_DRAG_CANCEL_NO_TARGET while Wayland GDK_DRAG_CANCEL_ERROR. Firefox got this as user cancelled the dnd action [2] so it won't move the tab to the new window [3].

Currently I'm trying to figure out with the GTK guys.

[1] https://gitlab.gnome.org/GNOME/gtk/issues/2101
[2] https://searchfox.org/mozilla-central/rev/3366c3d24f1c3818df37ec0818833bf085e41a53/widget/gtk/nsDragService.cpp#1308
[3] https://searchfox.org/mozilla-central/rev/3366c3d24f1c3818df37ec0818833bf085e41a53/browser/base/content/tabbrowser-tabs.js#806

Assignee: nobody → jhorak

This just started happening to me on Fedora 31. Did not happen on Fedora 30.

I installed firefox-x11 on fedora 31 and no longer have this issue. I'm guessing this is an issue with a new wayland version of firefox.

I'm working to make the DnD behaviour match closer in bug 1604048. That being said, it's not clear to me if it is actually possible to implement the "open new window on drop"-feature on Wayland cleanly: Wayland does not allow applications to position themselves, let alone know about their position. So the best we can do will probably be to open a new window at some position. So we'll have to evaluate if we should simply drop that feature on Wayland.

No, please don't drop it. Opening at some position would be okay, already, IMHO…

After all, the current behavior is a very confusing thing and a big UX downside, as I just cannot anymore "just drop" a window on another screen (as described in bug 1605717). So any solution would be better than no solution, as this behavior was a good pattern I've used/"trained" for years and don't wanna get rid of. It's way to convenient and having this unfixed would be a big inconvenience.

Just consider the "workarounds" other ways, which are way too inconvenient:

  • drag a tab on the same window and then (step 2) move it to the other screen
  • use some weird context menu on the tab to open it in a new window or (step 2) move it to another screen

(In reply to rugk from comment #21)

...as I just cannot anymore "just drop" a window on another screen...

Exactly that is not possible on Wayland. Actually for two reasons: the app can not control where to open a new window and it also doesn't know the cursor position (or even monitor) in the first place.

You would drop the tab on the other screen but the new window would appear on some other. So this feature would always be somewhat broken. And from a short talk on #wayland it doesn't look like this will change in the near future. On the other hand - opening the window somewhere might be better than nothing for some.

@robert For some reason firefox-x11 (XWayland) is able to do it.

Is there something XWayland can do that Firefox can't?

You would drop the tab on the other screen but the new window would appear on some other

That depends on the compositor, I would imagine many do open new windows on the screen where the cursor is currently.

Is there something XWayland can do that Firefox can't?

Of course, Xwayland is allowed to position X client windows wherever it wants — you can't support X11 applications any other way.

(In reply to bluelightzero from comment #23)

@robert For some reason firefox-x11 (XWayland) is able to do it.

Is there something XWayland can do that Firefox can't?

Yep. XWayland is not a normal application but something that needs to be baked into the Wayland compositor, allowing things that are not possible on pure Wayland. That's also the reason why it's hard to implement a native Wayland backend for Wine, but it's totally fine to run it through XWayland.

(In reply to greg v [:myfreeweb] from comment #24)

That depends on the compositor, I would imagine many do open new windows on the screen where the cursor is currently.

That's a good point.

Remove the GTK 2 workaround and check for GTK_DRAG_RESULT_USER_CANCELLED
instead of anything but GTK_DRAG_RESULT_USER_CANCELLED.

The above patch makes it basically work and also looks more correct to me than the previous solution (although the GTK side should still get fixed, but I'm not yet absolutely sure about that).

Unfortunately it only works sometimes. I think the rest is to blame on other DnD related bugs, therefore please leave the bug open if the above patch gets accepted.

Attachment #9123199 - Attachment description: Bug 1527976 - Use proper GTK enums. → Bug 1527976 - Use proper GTK enums, r=jhorak

And please can somebody make this bug block bug 1604048 ? That's where I plan to bundle some DnD related work.

Note that GTK_DRAG_RESULT_USER_CANCELLED simply doesn't exist in that form on Wayland yet...in apparently can't be implemented in the toolkit but needs to go into the compositor and neither Weston nor Mutter have it yet (cancelling a DnD operation by pressing esc for example). I'm looking into implementing it in Mutter in https://gitlab.gnome.org/GNOME/mutter/issues/1020, but it's not clear if the result can map one-to-one with the existing GTK enums.

Quote from https://gitlab.freedesktop.org/wayland/wayland/issues/140#note_396950:

Not quite the same, but I made mutter accept the "application/x-rootwindow-drop" mimetype on its background area, so at least you can keep dropping tabs (that would also offer that target) on empty desktop areas.

This actually allows us to implement the feature in a much cleaner way, without cancel animation and with proper indicator that a drop there is actually supported. I'll have a look into it.

(In reply to robert.mader from comment #31)

Quote from https://gitlab.freedesktop.org/wayland/wayland/issues/140#note_396950:

Not quite the same, but I made mutter accept the "application/x-rootwindow-drop" mimetype on its background area, so at least you can keep dropping tabs (that would also offer that target) on empty desktop areas.

This actually allows us to implement the feature in a much cleaner way, without cancel animation and with proper indicator that a drop there is actually supported. I'll have a look into it.

This unfortunately won't work for tiling window managers like Sway where there is no "background area" per se.

(In reply to Jonny Mako from comment #32)

This unfortunately won't work for tiling window managers like Sway where there is no "background area" per se.

Yep, but maybe the can help us out in the compositor, just like Mutter does here. When I start with this I'll talk to them (and the KDE people).

(In reply to Jonny Mako from comment #32)

This unfortunately won't work for tiling window managers like Sway where there is no "background area" per se.

Not true. Of course there is a background area — what do you see when no windows are opened? :) The background is just covered up more often, but you can put windows in floating (non-tiled) mode in tiling WMs too. Also, while I don't think sway supports this, some WMs can add gaps between windows (i3-gaps).

And either way, you'd want to support dropping onto other windows on non-tiling WMs too.

Attachment #9123199 - Attachment is obsolete: true
Blocks: 1604048

My workaround of this bug is by right clicking on the tab and then choose Move Tab > Move to New Window

Using right click, Move Tab > Move to New Window is how I workaround it as well. But when the tab header is near the right-hand side of the display, that second layer menu does not pop up. So I have to reorder that tab left in the order, and then Move to New Window.

That menu showing bug seems to happen when the second layer menu (under Move Tab) is triggered such that more than half of it overlaps with the top level menu, when it would want to flip pop-over direction to the left side instead of being displayed off the right side.

(In reply to Kyle Ferriter from comment #37)

But when the tab header is near the right-hand side of the display, that second layer menu does not pop up.

Sounds like Bug 1606010/Bug 1562576.

You can use an extension like Detach Tab if you want a keyboard shortcut to assist with detaching.

Assignee: jhorak → stransky
  • X11 uses MOZ_GTK_DRAG_RESULT_NO_TARGET to state no place for drop. Wayland does not have protocol for it and always return MOZ_GTK_DRAG_RESULT_ERROR.
    To emulate X11 behaviour for tab D&D (application/x-moz-tabbrowser-tab mime) don't chancel D&D operation on Wayland for MOZ_GTK_DRAG_RESULT_ERROR
    to allow to create a new tab when user drops tab outside the tab bar.
  • Provide some additional loging to D&D code.
Attachment #9139415 - Attachment description: Bug 1527976 [Wayland] Don't cancell Drag and Drop on MOZ_GTK_DRAG_RESULT_ERROR for application/x-moz-tabbrowser-tab (tab move), r?jhorak → Bug 1527976 [Wayland] Don't cancel Drag and Drop on MOZ_GTK_DRAG_RESULT_ERROR for application/x-moz-tabbrowser-tab (tab move), r?jhorak
Pushed by ccoroiu@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/a871f1b6b952
[Wayland] Don't cancel Drag and Drop on MOZ_GTK_DRAG_RESULT_ERROR for application/x-moz-tabbrowser-tab (tab move), r=jhorak

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

Status: NEW → RESOLVED
Closed: 4 years ago
status-firefox77: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla77

Thank you, this works for me on latest nightly and Sway 1.4.

Comment on attachment 9139415 [details]
Bug 1527976 [Wayland] Don't cancel Drag and Drop on MOZ_GTK_DRAG_RESULT_ERROR for application/x-moz-tabbrowser-tab (tab move), r?jhorak

Beta/Release Uplift Approval Request

  • User impact if declined: Major UI breakage under Wayland - users can't detach browser tab from tabbar.
  • Is this code covered by automated tests?: No
  • Has the fix been verified in Nightly?: Yes
  • Needs manual test from QE?: No
  • If yes, steps to reproduce:
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): Handles different wayland d&d behavior for tab bar ('application/x-moz-tabbrowser-tab') only.
  • String changes made/needed: none
Attachment #9139415 - Flags: approval-mozilla-beta?

Comment on attachment 9139415 [details]
Bug 1527976 [Wayland] Don't cancel Drag and Drop on MOZ_GTK_DRAG_RESULT_ERROR for application/x-moz-tabbrowser-tab (tab move), r?jhorak

Wayland-only fix. Approved for 76.0b8.

Attachment #9139415 - Flags: approval-mozilla-beta? → approval-mozilla-beta+

@ Martin: Are you sure this is working reliable for you?

I have seen you added this to firefox-75 on Fedora so I tried the same on Gentoo.
Please see the attached screencast. Sometimes I am able to drag a tab out of the window and get a new window like expect, but in most cases it's still failing.

PS: We are using mutter=3.34.5 and gnome-3.34.4 at the moment.

Works in 76.0b8 and sway 1.4 as well.

I second what @Thomas Deutschmann said. I am using archlinux with gnome 3.36.2 and neither firefox 76 nor nightly 78 from heftig's repo on wayland cannot get a tab to tear off into a new window.

Can you run firefox with MOZ_LOG="nsDragService:5" env variable, perform the unsucessfull D&D and attach the log here?
Thanks.

Flags: needinfo?(whissi)
Flags: needinfo?(pmargeti34)

Please see the requested logs.

It should contain 3 drag&drop actions. The first one was a drag&drop attempt to the left side of the screen, which failed. The second attempt was a drag&drop to the top of the screen (the gnome topbar) which also failed. The third attempt was a drag&drop attempt to the body of the screen which was successful.

Firefox 76.0 was used with mutter-3.34.6 on gnome-3.34.4.

Flags: needinfo?(whissi)

(In reply to Martin Stránský [:stransky] from comment #50)

Can you run firefox with MOZ_LOG="nsDragService:5" env variable, perform the unsucessfull D&D and attach the log here?
Thanks.

After today's update, first drag operation succeeds and a new window is spawned. Subsequent drag operations do not spawn additional windows.
List of updated packages:

[2020-05-06T11:00:24+0200] [ALPM] upgraded faad2 (2.9.1-2 -> 2.9.2-1)
[2020-05-06T11:00:24+0200] [ALPM] upgraded json-c (0.14-1 -> 0.14-4)
[2020-05-06T11:00:25+0200] [ALPM] upgraded firefox (76.0-1 -> 76.0-2)
[2020-05-06T11:00:25+0200] [ALPM] upgraded gvfs (1.44.1-1 -> 1.44.1-3)
[2020-05-06T11:00:25+0200] [ALPM] upgraded gvfs-afc (1.44.1-1 -> 1.44.1-3)
[2020-05-06T11:00:25+0200] [ALPM] upgraded gvfs-goa (1.44.1-1 -> 1.44.1-3)
[2020-05-06T11:00:25+0200] [ALPM] upgraded gvfs-google (1.44.1-1 -> 1.44.1-3)
[2020-05-06T11:00:25+0200] [ALPM] upgraded gvfs-gphoto2 (1.44.1-1 -> 1.44.1-3)
[2020-05-06T11:00:25+0200] [ALPM] upgraded gvfs-mtp (1.44.1-1 -> 1.44.1-3)
[2020-05-06T11:00:25+0200] [ALPM] upgraded gvfs-nfs (1.44.1-1 -> 1.44.1-3)
[2020-05-06T11:00:25+0200] [ALPM] upgraded jansson (2.12-1 -> 2.12-2)
[2020-05-06T11:00:25+0200] [ALPM] upgraded gvfs-smb (1.44.1-1 -> 1.44.1-3)
[2020-05-06T11:00:25+0200] [ALPM] upgraded luajit (2.0.5-2 -> 2.0.5-3)
[2020-05-06T11:00:25+0200] [ALPM] upgraded simple-scan (3.36.2-1 -> 3.36.2.1-1)
Flags: needinfo?(pmargeti34)

The log looks identical, I'd need to add more logging to the d&d code.

Anyway, filed as Bug 1635757.

See Also: → 1635757
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: