1974475 - [linux] Rearranging the pinned tabs by throwing them around pinned tabs might overlap and break the UI

Status: NEW

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

Description

[Rares Doghi, Desktop QA]

Attachment: Screencast from 2025-06-27 19-15-34.webm

Found in

• Nightly 142.0a1 (2025-06-27)

Affected versions

• Nightly 142.0a1 (2025-06-27)

Affected platforms

• Ubuntu

Steps to reproduce

1. Have at least 6 Pinned tabs. (More tabs easier to reproduce)
2. Grab random pinned tabs and change their position by trying to move them to the end or the start of the Pinned section really fast.
3. Grab the tabs from the edge of the pinned section and throw (I say throw because I lift my finger from the left mouse click before the tab lands into a new position) them to the middle. (Needs a mouse)

Expected result

• Pinned items should simply change position without issues.

Actual result

• The Pinned items start to overlap eachother and the entire UI is broken.

Regression range
Ill try to get a regression range for this issue since it doesnt happen in Beta or on Windows and Mac

Comment 1

[:Gijs (he/him)]

I wonder what the connection between this and bug 1955112 ends up being, but I expect there to be one. Rares, can you actually get a reliable regression window here? I am a bit worried that we don't fully understand the STR just yet and that it's somewhat random.

Are there any errors in the browser console when this happens?

Comment 2

[Rares Doghi, Desktop QA]

Its hard to reproduce this issue, I usually keep trying until it happens, I dont have any real steps and no there are no errors in Console, I reproduced the issue in our latest Nightly builds and I did not see any errors.

Comment 3

[Stuart Colville [:muffinresearch]]

Downgrading based on comment 2.

Comment 4

[Sarah Clements [:sclements]]

Hi Rares, are you seeing this issue in the latest Nightly?

Comment 5

[Rares Doghi, Desktop QA]

Yes this issue still occurs in our latest Nighly 143.0a1 (2025-07-24)

Comment 6

[:Gijs (he/him)]

(In reply to Rares Doghi, Desktop QA from comment #5)

Yes this issue still occurs in our latest Nighly 143.0a1 (2025-07-24)

Is this now also happening on 142 beta or no?

Comment 7

[Rares Doghi, Desktop QA]

Attachment: Screencast from 2025-07-25 14-54-57.webm

Yes I was able to reproduce the issue in our latest Beta 142.0b2

Comment 8

[:Gijs (he/him)]

:stransky, would you mind taking a look? Thanks and sorry. 😔

Comment 9

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

If bug 1955112 is related we hit a Wayland D&D issue here (Bug 1622107). Before bug 1955112 if there's unfinished D&D operation (D&D ended outside of Firefox window or double-tap or so?) we canceled the D&D operation. That led to unfinished D&D on Firefox UI and blocked user interaction here as UI expected input from D&D (was triggered by Bug 1957434 as it adds more check to D&D finish perhaps?)

So out Wayland D&D workaround for unfinished D&D was changed to actually finish the hanging D&D and it looks like it leads to this one - we're finishing D&D in the middle. IMHO if the workaround produces this outcome I think it may be reproduced by users as well without it by just dropping D&D early.

So right now we know that we're starting another D&D while the latest one was not finished:
https://searchfox.org/mozilla-central/rev/91b099f5033ae989b54d62c719442e3ecc5a1212/widget/gtk/nsWindow.cpp#7511

which we're hitting here. I just need to know which event we should deliver to front end to finish the pending D&D correctly (looks like both cancel or finish has its drawbacks or were not implemented correctly).