Open Bug 1711465 Opened 5 years ago Updated 1 year ago

[Wayland] D&D of tab may not create a new window

Categories

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

defect

Tracking

()

People

(Reporter: stransky, Unassigned)

References

(Blocks 2 open bugs)

Details

D&D of tab may not create a new window.

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

I don't think this is related - I suppose we see a race condition between Gtk and Firefox wl_data_offer handlers here.

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.

No longer blocks: wayland-nightly
Priority: P1 → P2

Can you try latest nightly with async clipboard enabled (https://bugzilla.mozilla.org/show_bug.cgi?id=1725149#c5)?
Thanks.

Flags: needinfo?(stransky)
Flags: needinfo?(stransky)

Martin, is this still a problem? I've never seen the issue live.

Flags: needinfo?(stransky)

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.

What's CSD ?

Client-Side Decoration (CSD) (browser.tabs.inTitlebar = 1).

xdg-toplevel-drag-v1 may be a solution for it (Bug 1955820).

Blocks: linuxdad
Flags: needinfo?(stransky)
You need to log in before you can comment on or make changes to this bug.