[Wayland] D&D of tab may not create a new window
Categories
(Core :: Widget: Gtk, defect, P2)
Tracking
()
People
(Reporter: stransky, Unassigned)
References
(Blocks 2 open bugs)
Details
D&D of tab may not create a new window.
Comment 1•5 years ago
|
||
For the record: I recently talked to a Chromium dev at Igalia who proposed a new Wayland protocol for exactly this use-case: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/46
| Reporter | ||
Comment 2•5 years ago
|
||
I don't think this is related - I suppose we see a race condition between Gtk and Firefox wl_data_offer handlers here.
Comment 3•5 years ago
|
||
I just wanted to mention it as this protocol would allow us to properly differentiate between successful and cancelled drops (e.g. pressing Esc). Just to let you know that in the future we might have better Wayland API. But you're right, it's not related to the specific bug you want to fix here.
| Reporter | ||
Updated•5 years ago
|
| Reporter | ||
Comment 4•4 years ago
|
||
Can you try latest nightly with async clipboard enabled (https://bugzilla.mozilla.org/show_bug.cgi?id=1725149#c5)?
Thanks.
| Reporter | ||
Updated•4 years ago
|
Comment 5•1 year ago
|
||
Martin, is this still a problem? I've never seen the issue live.
I see this when dragging tabs directly above the window on Ubuntu 24.10 with CSD enabled, a new window is only created when dragging does not cross the top edge of the window. Enabling the native titlebar (browser.tabs.inTitlebar = 0) avoids the issue for horizontal tabs but not for vertical tabs.
Comment 7•1 year ago
|
||
What's CSD ?
Client-Side Decoration (CSD) (browser.tabs.inTitlebar = 1).
| Reporter | ||
Comment 9•1 year ago
|
||
xdg-toplevel-drag-v1 may be a solution for it (Bug 1955820).
Description
•