Selecting a different tab while moving the cursor (dragging) may move it to new window #2078
Labels
Comments
|
Could you collect logs for the problem "a clicked tab is unexpectedly detached from the window", in the debug mode? Steps:
|
|
The setting is Firefox with a single window and two loaded non-nested tabs. The first tab has been selected and a click-while-dragging action is performed on the second one, with both the button press and button release actions perfomed on its surface: |
|
Thanks! The log says that some odd things happened on your environment:
Hmm... |
|
By recent commits I've changed the logic to detect the dragging action is finished on dragged tabs themselves or not. I hope this change solves the problem. |
|
Going to Given the difficulty of reproducing the issue with the change of settings, I have had trouble capturing a clean debug output. To my eyes, the starting, intermediate and ending positions of the mouse cursor in the test that resulted in the following output were quite clearly inside the tab and the sidebar: Despite that certainty of mine about the cursor placement, I am not sure that the output agrees. Note that I resized the sidebar to its maximum width, which looks to be around 862 physical pixels from the left edge of the window when examined on a screenshot and that the screen is a Retina one with the scaled horizontal and vertical resolutions set to half the physical ones. |
|
I still experience the issue with TST 2.6.8.7790 (downloaded ten minutes ago) running on Firefox 65.0a1 (2018-11-22) (64-bit) and macOS 10.14.1. Mouse release coordinates continue to be reported as (0, 0). |
|
Sorry my previous changes were incomplete. The flag On the other hand, another problem "clicking on a background tab triggers dragstart unexpectedly" is still there. It look unsolvable until any new API to warm up tabs https://bugzilla.mozilla.org/show_bug.cgi?id=1402256 become available. |
|
Using a Firefox 65.0a1 nightly, the results of testing TST 2.6.8.7792 are:
Thank you for your time and for the fix! |
|
The problem as described at the beginning of this thread is happening again with Tree Style Tab 2.8.5 on Firefox 65.0.2 on macOS 10.14.3, so I am reopening the issue. If it should warrant a different report (given the logs below or for some other reason) let me know or feel free to open one. In this instance, the “sidebar/mouse-event-listener” and “sidebar/drag-and-drop” debug logs for a click-while-dragging are as follows: The specific actions were:
Thought the above log output is for TST 2.8.5, the behaviour is also reproducible with version 2.8.0, but not so with version 2.7.23. |
|
I have tried to reproduce the situation again today and I can't get to reproduce the renewed issue exactly as I described it nor with the same consistency. I will try further before making any other observations so as not to further muddy the waters. |
|
FYI: I've done the migration of the core architecture of TST planned at #2139. More testing with the latest development build is required. |
|
I close this because outdated. |
|
There are now two instances which feel slightly different (tested using and unbranded build of Firefox 66.0.3 and the 3.0.10.9081, 2019-05-03 01:58, development build of Tree Style Tab) in which a tab is unexpectedly detached. The first case is when clicking down during uninterrupted mouse movement. When releasing the click, the tab gets moved to a new window: The second case is when moving the mouse over a tab and stopping the mouse movement at the same time at which the mouse button is clicked down. In this case, the tab gets detached while the mouse button is still held down (as can be seen in the capture, where the mouse button release happens several seconds after the drag event is reportedly finished): |
|
The originally described behaviour still happens with 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): |
|
Is this really closed? I'm seeing this exact problem. I hoped there would be a fix being worked on. |
Check issue #2444 and consider increasing the value of the |
|
Hello and thanks so much for that very fast response. I have set the value
to 1000 and will see if it helps.
Cheers, Graeme
…On Tue, 17 Mar 2020 at 17:54, Gonzalo Higuera Díaz ***@***.***> wrote:
Is this really closed? I'm seeing this exact problem. I hoped there would
be a fix being worked on.
Check issue #2444 <#2444>
and consider increasing the value of the maximumDelayForBug1561879 option
(under “All Configs” of the “Development” section of the extension's
preferences): A workaround involving a delay to drag and drop operations on
coordinate (0, 0) was introduced with commit 4b591bc
<4b591bc>.
Since it was too short for me and the optimum value was not clear the
default was not changed, but it was made user-adjustable. I personally tend
to it set to 1000 milliseconds (perhaps excessive: 500 or even lower also
does the trick for me) since the only side effect I observe is not being
able to drag and drop tabs in that time frame to one corner of the screen,
which is a non-issue for me.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#2078 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AL25NMVHRSNWZ4FP3HC4HYLRH4NCJANCNFSM4GFTKXUQ>
.
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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:
Steps to reproduce
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
Observations
Regarding TST, the behaviour seems to begin with version 2.5.3. Some aspects of clicking an unselected tab while moving the cursor might be a little different if done outside of the described steps (e.g. dragging the unselected, and perhaps unloaded, tab outside of its position), but that is not the focus of this report.
Regarding Firefox, some weirdness seems to begin with version 61 and TST 2.5.3 (or higher): in version 60, if the click-while-moving of an unloaded tab drags it to a new position in the tree, the tab seems to be properly moved there; with version 61 is tends to remain where it is, though it sometimes end in a new window (though I am tired of testing to feel too confident about it). Regardless of that, the problem as described in the non-optional ”steps to reproduce” seems more likely to happen starting with version 62 (and versions 63 and betas of 64). Note that with version 65 (e.g. nightly 65.0a1 (2018-11-20)) TST 2.5.2 tabs (and earlier) cannot be moved around, so the change of behaviour from 2.5.2 to 2.5.3 described in this issue can no longer be compared in them.
Regarding the rest of the environment, I believe that, the more heavily loaded Firefox is, the more likely the behaviour is to trigger: it is the constant misbehaviour in a long-lived profile with several windows and hundreds of tabs that has lead me to open this issue (in particular, the behaviour was triggered on a tree with many unloaded tabs, the new window they were dragged to bugged out and disappeared, and I found no trace under Firefox's “Recently Closed Windows”, which left me a little sore about not having described the situation earlier).
The text was updated successfully, but these errors were encountered: