1982316 - [wayland] Dragging active tab a small amount consecutively triggers double-click action that creates a new tab at end of vertical tabs list

Status: NEW

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

Description

[Kestrel]

Attachment: New tabs appearing when active tab dragged a small amount

STR:

1. Enable vertical tabs on latest Nightly 143.0a1 (Ubuntu 25.04, Wayland, GNOME).
2. Drag the active tab a small amount in any direction, not enough for the tab to move.
3. Repeat rapidly several times.

Expected:
Tab stays active and no new tabs are created.

Actual:
Tab sometimes loses active state as a new tab is created at the end of the tab list.

Does not happen when dragging inactive tabs.

XWayland, horizontal tabs and Windows 11 unaffected.

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=68d1a44fdef33f1256471aa630bebf080599dd4e&tochange=fdc1c87c70f2a9e1eea62291478ba1e3a4a5906f

Possibly regressed by Bug 1953193.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

:dao, since you are the author of the regressor, bug 1953193, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Comment 2

[Martin Stránský [:stransky] (ni? me)]

Yes, we need to handle that somehow. Right now we mark the drag as successful. We can try to flip it to failed but that leads to Bug 1955112.
I don't think we have much choice until root cause https://gitlab.gnome.org/GNOME/mutter/-/issues/740 is fixed.

Comment 3

[Kestrel]

(In reply to Martin Stránský [:stransky] (ni? me) from comment #2)

Yes, we need to handle that somehow. Right now we mark the drag as successful.

A successful drag would not create a new tab though, the dragged tab is not being copied.

Double-clicking the empty tab bar creates a new tab and this bug only happens when the drag operations are done in quick succession like a double-click so it seems like the click events are going to the wrong place.

Comment 4

[Thinker Li [:sinker]]

Hi Martin, should we just send a dragend if receiving a button down event during a D&D session?

Comment 5

[Martin Stránský [:stransky] (ni? me)]

Bug 1979719 has latest iteration of the Wayland workaround - we terminate D&D if we don't get any drag motion event (so we don't receive drag end too).

We see this bug because we terminate the failed D&D as successful:
https://searchfox.org/mozilla-central/rev/270c20e4b063d80ce71f029b4adc4ba03a12edc0/widget/gtk/nsWindow.cpp#7521

We used 'drag failed' before but that caused rather critical Bug 1955112.
We may try to flip to 'drag failed' for Nightly only to see how it works after Bug 1979719 changes but we definitely should not release such change before testing.

Comment 6

[Martin Stránský [:stransky] (ni? me)]

Kestrel, does it really affects Firefox 142? I think it's a regression from Bug 1979719.
Thanks.

Comment 7

[Martin Stránský [:stransky] (ni? me)]

Filed the nightly-only change as Bug 1983750.

Comment 8

[Kestrel]

Attachment: Version 141 showing same issue

(In reply to Martin Stránský [:stransky] (ni? me) from comment #6)

does it really affects Firefox 142?

Yes, it goes back to version 138.

Comment 9

[Martin Stránský [:stransky] (ni? me)]

Okay, let's retest when Bug 1983750 lands.

Comment 10

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1953193

Comment 11

[Martin Stránský [:stransky] (ni? me)]

Kestrel, can you please check latest nightly with Bug 1983750 fixed?
Thanks.

Comment 12

[Kestrel]

Attachment: Additional breakages after Bug 1983750

Problem still happens with more breakage. The dragged tab stops responding to clicks and stays floating in position when scrolling the list. A blank space appears at the end of the list. Dragging a different tab corrects the list state.

Comment 13

[Martin Stránský [:stransky] (ni? me)]

Okay, so Bug 1983750 is backed out and we have "a new tab" behavior back.