Selecting a different tab while moving the cursor (dragging) may move it to new window

[gonhidi]

Short description

When selecting a different tab by clicking on it using the Tree Style Tab (TST) sidebar, if the cursor has any motion the newly-selected tab (and its siblings) might end up in a new window.

Reference tab structure:

A (current)
B

Steps to reproduce

1. Start Firefox with clean profile.
2. Install TST.
3. Create the reference tab structure.
4. (Optional) To improve the chance of triggering the behaviour by quite a bit, unload the unselected tab B (e.g. configure Firefox to save the session and restart it).
5. Click on unselected tab B while moving the cursor within the tab (fast movement and clicking, a sort of blitz drag-and-drop, improves the chances of triggering the behaviour).

Expected result

Since the cursor movement has been within the tab, the newly selected tab B should remain within its position.

Actual result

The newly selected tab B has a chance to be dragged to an entirely new window (along with any tabs hanging from it).

Environment

• Platform (OS): macOS 10.14.6
• Version of Firefox: 71.0.0
• Version (or revision) of Tree Style Tab: 3.2.6

Observations

This is basically issue #2078 tested on an up to date version of Firefox and TST.

[gonhidi]

This is a debug log tested with an unbranded Firefox 71.0.0 on macOS Mojave 10.14.6 using the development Tree Style Tab 3.2.6.9832 (tested on unloaded tabs):

tst<Sidebar-3>: 14:45:25.772 sidebar/mouse-event-listener:      onMouseDown: found target tab:  
Object { id: 21, index: 20, windowId: 3, highlighted: false, active: false, attention: false, pinned: false, status: "complete", hidden: false, discarded: true, … }
common.js:382:13
tst<Sidebar-3>: 14:45:25.774 sidebar/mouse-event-listener:      onMouseDown  
Object { targetType: "tab", tab: 21, tabId: 21, window: 3, windowId: 3, twisty: false, soundButton: false, closebox: false, button: 0, ctrlKey: false, … }
common.js:382:13
tst<Sidebar-3>: 14:45:25.776 sidebar/mouse-event-listener:       Sending message to listeners common.js:382:13
tst<Sidebar-3>: 14:45:25.818 sidebar/drag-and-drop:      onDragStart: start  
dragstart { target: tab-item#tab-21.animation-ready.complete.contextual-identity-firefox-default.tab.discarded
, buttons: 1, clientX: 178, clientY: 351, layerX: 141, layerY: 10 }
 
Object {  }
common.js:382:13
tst<Sidebar-3>: 14:45:25.827 sidebar/drag-and-drop:      onDragStart: started common.js:382:13
tst<Sidebar-3>: 14:45:25.891 sidebar/mouse-event-listener:      onMouseUp:  
Object { id: 21, index: 20, windowId: 3, highlighted: false, active: false, attention: false, pinned: false, status: "complete", hidden: false, discarded: true, … }
 
Object { living: true }
common.js:382:13
tst<Sidebar-3>: 14:45:25.899 sidebar/drag-and-drop:      onDragEnd,  
Object { mDraggingOnSelfWindow: true, mDraggingOnDraggedTabs: true, dropEffect: "none" }
common.js:382:13
tst<Sidebar-3>: 14:45:25.900 sidebar/drag-and-drop:     finishDrag common.js:382:13
tst<Sidebar-3>: 14:45:26.076 sidebar/drag-and-drop:     finishDrag common.js:382:13
tst<Sidebar-3>: 14:45:26.153 sidebar/drag-and-drop:     workaround for bug 1548949: detect dragged tabs are handled by me or not. 
Object { handledBySomeone: false, draggedTabs: "1577886212651-63956/21", lastDroppedTabs: "" }
common.js:382:13
tst<Sidebar-3>: 14:45:26.156 sidebar/drag-and-drop:     dragend at:  
{…}
​
devicePixelRatio: 2
​
eventClientX: 0
​
eventClientY: 0
​
eventScreenX: 0
​
eventScreenY: 0
​
fixedEventScreenX: 0
​
fixedEventScreenY: 0
​
offset: 12.099998474121094
​
windowH: 694
​
windowW: 432
​
windowX: 4
​
windowY: 140
​
<prototype>: Object { … }
common.js:382:13
tst<Sidebar-3>: 14:45:26.157 sidebar/drag-and-drop:     trying to detach tab from window common.js:382:13
Unhandled Error:  Error: "Invalid tab ID: 28" createErrorHandler@moz-extension://de42b06d-f2fd-b346-8e04-811e2b21e723/common/api-tabs.js:85:34
request@moz-extension://de42b06d-f2fd-b346-8e04-811e2b21e723/common/unique-id.js:102:100
updateUniqueId@moz-extension://de42b06d-f2fd-b346-8e04-811e2b21e723/common/Tab.js:208:21
checkRecycledTab@moz-extension://de42b06d-f2fd-b346-8e04-811e2b21e723/background/api-tabs-listener.js:634:14
onNewTabTracked@moz-extension://de42b06d-f2fd-b346-8e04-811e2b21e723/background/api-tabs-listener.js:559:23
api-tabs.js:109:17
Unhandled Error:  Error: "Invalid tab ID: 28" createErrorSuppressor@moz-extension://de42b06d-f2fd-b346-8e04-811e2b21e723/common/api-tabs.js:117:34
request@moz-extension://de42b06d-f2fd-b346-8e04-811e2b21e723/common/unique-id.js:144:109
api-tabs.js:145:17

[piroor]

eventClientX: 0
​>
eventClientY: 0
​>
eventScreenX: 0
​>
eventScreenY: 0

These log mean that the window was positioned at top-left edge of the screen and you released the mouse button at the top-left edge of the screen. Otherwise did you activate the option privacy.resistFingerprinting? It breaks TST's functionality and sadly there is no solution for now. See also: https://bugzilla.mozilla.org/show_bug.cgi?id=1448848

[gonhidi]

For the test I used a new profile, only setting xpi.signatures.required to false in order to install the nightly version of the extension on the unbranded Firefox build. I have repeated the test on a new profile, confirming that privacy.resistFingerprinting is the default false and making sure that the Firefox window and the tabs are not near the edge of the screen, and again the event coordinates you listed all show up as zero (similarly to what was happening in logs from issue #2078).

[gonhidi]

I see that on commit 4b591bc you introduced a workaround which is still present on 3.2.6:

treestyletab/webextensions/sidebar/drag-and-drop.js

Lines 1184 to 1188 in 3505cd3

	// On macOS sometimes drag gesture is canceled immediately with (0,0) coordinates.
	(Date.now() - mLastDragStartTime < 100 &&
	event.screenX == 0 &&
	event.screenY == 0)) {
	log('dropped near the tab bar (from coordinates): detaching is canceled');

Building a version with a less tight timing window than the current 100 ms seems do do the trick for me; I have tested setting it to 2000. I don't know what a reasonable value might be: given the last log, 300 ms wouldn't be enough, and I have just experienced a delay of around 700 ms (from the log window: 19:06:05.527 “onDragStart”, 19:06:06.257 “workaround for bug 1548949”).

[piroor]

Oops, sorry I totally misunderstood the context. Now I've realized that the original issue was produced with a poor performance of old TST and it looked fixed with a performance improvement, but it has looked to be reappeared from same reason.

[piroor]

Anyway this problem is fundamentally caused by the bug 1561879 - Sometimes drag operation started in a sidebar contents provided by an addon is immediately canceled on macOS. I've introduced a change to make the delay configurable with the commit ccda491. It may help you to use TST without custom build.

[gonhidi]

That is a really welcome option. Thank you! Adjusting the delay through the new TST option works for me in the testing I have done using an automated build. I imagine that it will prove to be equally effective once the stable build gets pushed out and I try it on my main profile. Given that the root issue depends on a Firefox fix and that there's this workaround, I will now close this issue.

[stijnherreman]

Just for the record, I'm experiencing this on a Windows system so it seems it's not macOS specific.