Suddenly unable to move tabs #1778
Labels
Firefox-issue
bug of Firefox itself
Comments
|
Removing TST and reinstalling it did fix the problem but if anyone happens to know what can cause this so I can avoid doing it again that information would be greatly appreciated. |
|
I have the exact same issue on OSX. Sometimes the error occurs, sometimes it doesn't. In the developer toolbox, I see the following error when opening a tab with the button in the sidebar (but not when opening a tab with Command+T) When closing a tab using the standard mechanism (Command+w), see the following error I have no idea if either of those errors has anything to do with TST. |
|
@danielzfranklin Thanks, but I couldn't read meaningful information from the log. If you see same problem again, could you collect logs from the debugger? Steps to start debugger: |
|
I activated debug mode, and got the following logs when dragging a tab I'm not certain, but the error seems to occur only when there is a pinned tab (It's infrequent enough it could be a coincidence). |
|
This stuff is sometimes happening to me too, tabs get greyed out when trying to move them around the tree. Happens usually after the pinned tab was used (by used I mean even just opened). The remedy for that is for me to click again on the pinned tab to open it, then the locked (grey) tabs are suddenly unlocked and everything is just fine. |
|
I still couldn't reproduce this problem on my environment, with the latest development build. From different viewpoint, I'm trying to analyze what happens when tabs become undraggable.
If your case is in on of emphasized cases above, it is an intentional result. |
|
Steps to reproduce:
Expected result: One should be able to continue moving tabs around. Actual result: At some point one is no longer able to drag around any of the tabs. Workaround: One the problem is triggered, move a tab (within the window or to a new window) using Firefox's native tab interface (the horizontal tab); this seems to unlock dragging using the sidebar's extension (but I have just noticed so testing has been minimal and I might be wrong). The following debug log based on a single restored window with a search engine tab with around 30 sub-tabs obtained from middle clicking on search engine's results page, plus a few other tabs. I tried quickly dragging around four different tabs: one moved for sure (as it ended up as a sub-tab); of the rest I am not certain. I then tried calmly dragging one more tab and it clearly did not work (but due to the extension's theme and debugging being enabled I did not notice the greying out that happens when I run across this on my usual setup). I then captured the log and afterwards confirmed that none of the other tabs I tried could be moved around. I did not record what happens when using the described workaround. |
|
@gonhidi Thank you for the log. However, I'm sorry but I've realized that I forgot to output more logs to inspect why the drag action is canceled. Could you try again with a newer development build of TST? Please note to setting debug logs as:
|
|
@piroor Sorry for not being more aware of how Firefox and Tree Style Tab logging and debugging work to help produce better results, and thank you for providing a build and instructions to allow for more useful results. Using the latest development build at the time of testing, version 2.4.24.7383, I followed my previously described setup, taking care to enable Tree Style Tab's debug mode and to disable detailed logging except for the sidebar/drag-and-drop and sidebar/mouse-event-listener options (as described). From there I proceeded to reproduce the situation in a similar vein as last time, which I will now describe broken down in steps with the corresponding debug log outputs. First I tried to drag and drop two session-restored but not yet accessed tabs in quick succession within the Tree Style Tab sidebar (I am not sure about the result): I then unsuccessfully tried to move the currently selected tab in the Tree Style Tab sidebar: Afterwards, I successfully moved the currently selected tab using Firefox's native horizontal tabs (the aforementioned workaround) one to the left: Finally, I successfully dragged and dropped the currently selected tab in the Tree Style Tab sidebar five to ten tabs up: |
|
Addendum: It is actually not necessary to drag and drop more than one tab for the locking behaviour to happen. Quickly trying to drag and drop a restored but not yet loaded tab within an Tree Style Tab sidebar that was working can also lock it and prevent the tab from being moved, resulting in the following debug log output: |
|
@gonhidi Thanks again! Hmm, your log says that handling of dragstart event is not canceled intentionally. So, the dragging action may be canceled by any unexpected error or other reasons. I've updated the development build with more logs, so could you try it again? |
|
@piroor Using Tree Style Tab 2.4.24.7392 and only doing as before (i.e the “unsuccessfully trying to drag and drop a restored but not yet loaded tab within an Tree Style Tab sidebar that was working”) shows the following: |
|
Thanks! The result is very interesting. The log says that dragging action was successfully started but there is no report about dragover/dragenter/dragleave events, that is quite unexpected... |
|
I think that the drag action is possibly canceled by loading of a pending tab. However, Firefox on Ubuntu doesn't produce such a problem on my environment. Hmmm.... |
|
Could you try another addon together with TST?: https://addons.mozilla.org/firefox/addon/move-unloaded-tabs-for-tst/ It prevents TST's default behavior "focus to the tab by mousedown" and you can drag and drop background pending tabs without activating. If the problem you saw is caused by "tab restoration on dragstart", it may become a workaround. |
|
With both extensions active (using the 2.4.24.7392 development build of Tree Style Tab) I can no longer reproduce (in my limited testing) this issue's behaviour the way that I previously described. The debug logs of a successful drag-and-drop of an restored-yet-unloaded tab using the sidebar/drag-and-drop and sidebar/mouse-event-listener options only are the following: (Observation: The tab I quick-moved was a sibling of a series of restored and unloaded tabs, and my action resulted in the dragged tab becoming a child of the second tab above it, with the quirk that its position didn't actually change position to reflect the change. In other words: having three consecutive sibling tabs and moving the lower one onto the upper one resulted in them unexpectedly remaining in the same position in both the TST sidebar and the Firefox-default horizontal tab section, with the lower becoming properly registered as a child of the upper one, as proven by the indentation and by the upper one gaining the arrow allowing to hide its misplaced new child. This might likely be an issue unrelated to both the current one and its possible workaround, since in my other quick-dragging experiments I have had no issues; but given that I have occasionally stumbled upon misplaced children — single tabs, groups of siblings, and perhaps also trees — yet had had little chance in reproducing the circumstances — which I have mainly noticed on session restore — I have decided to share as-is, hoping that it might help elsewhere without interfering with the evaluation of the issue at hand.) |
Thanks! I think this seems a bug of Firefox itself, and it should be filed like: "drag event is silently canceled when a pending tab is loaded by tab selection". The easiest way to "fix" this problem is: introducing new option or changing the default behavior of clicking on tabs, like "Move unloaded tabs for Tree Style Tab" does. However I don't want to do that because the behavior is different from Firefox's native horizontal tab bar. It's a hard issue... Anyway I should do something workaround for the edge case: canceled drag-and-drop action and already dispatched dragstart event. |
piroor
added a commit
that referenced
this issue
Jul 13, 2018
|
By the commit 3bad8ee, the "dragging" state will be cleared if the drag operation is unexpectedly canceled by a restoration of a pending tab. This change doesn't "fix" the problem: a background tab cannot be dragged. However, I think this should solve another problem: you cannot start dragging anymore after the first problem happens. Could you try the updated development build? |
|
Step by step experience using Tree Style Tabs (TST) 2.4.24.7401:
Although all this trouble might be a Firefox issue, given that this last step works and that I wouldn't be able to provide a simple test case or reasoning that it is their code or the interface they provide that is causing trouble here, I don't think that it would be appropriate for me to open a report; I would however be happy to follow it and provide whatever support is in my hands. |
|
Thank you for researching with details. And now I've successfully reproduced the problem on a macOS machine. I'm trying to research more... |
|
Could you try again with disabled e10s for addons? (Go to |
|
I've reported this problem to bugzilla.mozilla.org: |
|
I can confirm that after setting |
|
Good news. The Firefox-side bug https://bugzilla.mozilla.org/show_bug.cgi?id=1476195 has been closed as FIXED and the patch will be included at Firefox 71 and later. |
|
I haven't yet tested very thoroughly, but the issue does seem fixed on Firefox (Nightly) 71.0a1 (2019-09-13) on macOS Mojave 10.14.6 (18G95). Thanks! |
piroor
added a commit
that referenced
this issue
Sep 8, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Short description
Sometime within the past day I am suddenly unable to rearrange or move tabs in Tree Style. In addition, when I try to move tabs they become grayed out and do not move.
Steps to reproduce
Unfortunately I have no clue how to reproduce this behavior. It could have been something I unknowingly and unwittingly changed somehow. I only know it is a TST issue because I can still move tabs around in the native tab bar.
I am hoping someone might know what can cause this behavior so I can reverse whatever I did. I would not normally post an issue like this in a bug reporter but I have not been able to find where else to ask.
Thank you.
Expected result
Actual result
Environment
The text was updated successfully, but these errors were encountered: