1491496 - Attempting to drag a background tab fails when clicking on the tab where its close button will appear

Status: NEW

(Firefox :: Tabbed Browser, defect, P3)

Description

[Stephan Sokolow]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:63.0) Gecko/20100101 Firefox/63.0
Build ID: 20180906162647

Steps to reproduce:

Habitually use drag-and-drop to reorder browser tabs and it'll happen sooner or later... seemingly at random.


Actual results:

Sometimes, the tab focuses but doesn't start dragging.

I've tested the following hypotheses but have yet to find a reliable reproduction:

1. Maybe discarded tabs don't drag on the click that focuses them and triggers them to load back in? (No. Works fine under test.)

2. Maybe I'm accidentally clicking outside the active region? (No. Aside from the tiny slice to the right of the close button, everything that is visibly part of the tab responded to dragging under test conditions.)

Currently, my hypothesis is that it's some kind of race-condition or jank artifact related to my having 360 tabs spread across four Firefox windows with 38 extensions installed on a mere dual-core Athlon II X2 270 CPU.

(I really need to find some kind of tool for reliably simulating certain load conditions so I can provide reproduction instructions for all the races I keep finding beyond "1. Bog down the browser enough".)


Expected results:

A click-and-drag on what is visibly part of the tab should always initiate a drag-reorder process.

Comment 1

[Stephan Sokolow]

Actually, I think it *is* related to the tabs having been discarded.

While my first attempt to reproduce the problem allowed me to drag a tab that had been discarded before I grabbed it but, now, it seems like my first click on a discarded tab cannot be the beginning of a drag.

I'll try to fit in some more testing today or tomorrow.

Comment 2

[Stephan Sokolow]

...and now it happened with a tab I'd opened by middle-clicking, which leads me to suspect it's not the discarded state itself which the problem is related to, but the loading state that the initial mousedown on a discarded tab triggers.

Comment 3

[Alex Thayer [:alexical] (she/her)]

I've noticed that this happens to me when I accidentally start my drag from within the close tab button on a tab. Could this be what you're running into? (If so, it still is a bit frustrating, and maybe we can do something about it, but it's not altogether straightforward. The general pattern for mousing down and dragging off of a button is to simply cancel the button press.)

Comment 4

[Stephan Sokolow]

A very insightful point and I think I now know what's going on.

The primary situation where I encounter this involves dragging a tab that is un-focused and, thus, has no X at the time of the initial mousedown event.

It appears that the bug is triggered as follows:

1. Open enough tabs to shrink them down to barely more than icons
2. Attempt to drag a tab while grabbing it anywhere other than the left-most third or so.
3. The X will pop into existence under the cursor.
4. While the mousedown doesn't register as the beginning of a click on the close button, it's still enough to block the start of a drag-and-drop operation.

Also, even the blocking is a little screwy. The hover highlight for the X doesn't block drag and drop, but the bounding box for the glyph does... but the bounding box starts a couple of pixels into the left edge of the visible glyph.

Aside from making tabs draggable by their close buttons, the other solution would be to determine whether to initiate a drag based on the DOM node that was under the cursor at mousedown, rather than later on in the process.

(So this is sort of like the bug I've been meaning to diagnose and report to the appropriate tracker where, if the provider of clipboard content is bogged down, typing [url=<Ctrl+V>] can result in [url=]<pasted text> because some component in the system isn't keeping track of where the cursor was when at the time Ctrl+V was pressed.)

Comment 5

[Stephan Sokolow]

While it's true that the drag fails when focusing the tab causes the close button to appear below the cursor, I'm still noticing an intermittent failure to drag discarded tabs when I've been very careful to start in a region where the close button will not appear.

It could be the same root cause, given that, so far, I've only reproduced it when attempting to quickly click-drag a discarded tab to the right.

(Is it possible that initiating an un-discard is sometimes causing a delay between the click and start-of-dragging handling? That'd allow "start-of-dragging handling is identifying the element under the cursor too late in the process" to cause both behaviours if, in the intermittent case, the determining factor is whether the cursor has moved over the X by the time the start-of-dragging part fires.)