Open ronso0 opened 6 years ago
Encountering the same bug on Firefox 60.0.1 (64-bit), Windows 7 x64. I went through all 12 addons in my Firefox only to know Tab Control causes this bug. Thanks for reporting this ronso0.
@ronso0, @rocketaz, sorry for replying late, let's try and figure out what may be causing this.
I use this option to restore windows and tabs myself and there are always at least a few tabs open, but I haven't encountered this issue, I'm sure I would have noticed. Just now I've clicked several links on Github, then restarted the browser and it looked fine afterwards. There must be more factors that contribute to triggering the issue.
If the bug occurs every time Firefox is closed and restarted, could there be more steps I need to perform to reproduce the issue, or could you write them in a greater detail?
Do you have any other add-on that might be opening or re-ordering tabs on browser startup?
@czukowski Thanks for taking care! Now that I got used to this bug, I don't experience it anymore ;) I didn't upgrade FF nor did I change any addons. The only tab-related addon I use is Tab Session Manager, but I disabled all automatic behaviour, use it only for manual save/restore of research sessions.
I'll watch this..
@ronso0 could you try enabling some automatic behaviour of your Tab Session Manager? If the bug appears again, then we'll know it has to do with a conflicting behavior of the two add-ons, and if not, then the problem must be somewhere else and not in how Tab Session Manager and this add-on interact with each other.
For some reason I didn't notice the bug anymore, now it popped up again.
Only TabControl is enabled. If I disabled that, as well, tab order persists a restart. With TabControl, after every start of FF the tab order is reversed, so every second start it's fine ;) I updated FF to 60.2, still the same issue.
To be 100% sure I created a blank FF profile:
Additionally, I tested both FF's and TabSessionManager's session restore functions independently in that vanilla profile: both work fine with TabControl disabled
@ronso0 weird, I've just tried the same, with a blank profile as well, and it wouldn't reproduce. The tab order is the same (and correct) with Tab Control both enabled and disabled... Do you close FF by closing its window, or via menu -> quit? After you close it, is the process still there, or is it terminated?
I noticed some weird behavior when I left the Browser console open from Developer tools menu, just closing the window would not quit FF completely and upon restart the currently active window was replaced by a 'new tab' page, but that seemed to be the same regardless of whether the add-on was enabled or disabled.
I'll try to examine the source code again and see where could be the problem and whether it is possible to delay the initialization in a sensible way, although it probably wouldn't be easy without reproducing the issue...
I quit FF by closing its window (X) mostly before shutting down my system. I rarely use dev tools.
I know that delaying the start of the addon is just a hack. If you could supply a patch introducing a start delay I'd be happy to test it on my sys
Btw I notice that the tab order is not completely reversed, sometimes there are just the first few tabs mixed up with those from 'the other end of the tab row' (have ~50 tabs)
@ronso0 here are a few attempts of delaying the initialization:
tab_control_dev-1.1.2a1-an+fx-delay-50ms.zip - by 50 ms tab_control_dev-1.1.2a2-an+fx-delay-100ms.zip - by 100 ms tab_control_dev-1.1.2a3-an+fx-delay-200ms.zip - by 200 ms tab_control_dev-1.1.2a7-an+fx-delay-1000ms.zip - by 1 s tab_control_dev-1.1.2a4-an+fx-delay-2000ms.zip - by 2 s tab_control_dev-1.1.2a5-an+fx-delay-5000ms.zip - by 5 s
Note: these have a different web extension ID than the add-on on AMO and will not overwrite it, so the 'default' add-on needs to be disabled manually in order to not conflict with these development versions.
Please let me know if any of these helps.
Edit: copied a few more download links from a later comment
After several tests (Tab Control 1.1.1) on my FF profile with other 12 Add-ons, all seems working fine now. This could be because of others Add-ons has updated for the past 2/3 weeks. Currently, tab related add-ons I have installed are Glitter Drag and Shortkeys (Custom Keyboard Shortcuts). I'll keep you posted if there is bug come jump up again. Thanks @czukowski
Thanks @czukowski I tried the 200ms version and it didn't solve the issue. It would be kind if you'd supply a version with an extreme delay of let's say 2000ms, or point me to some comprehensive low-level ressource telling me how to re-build the addon (checksums) on my own.
@ronso0 to sign extensions, you'd have to register on AMO and generate access tokens, which I'd say is too much hassle if you want to just test something. Though after the initial setup, it's as easy as running a program from command line.
Here are some longer delays for you to try:
tab_control_dev-1.1.2a4-an+fx-delay-2000ms.zip tab_control_dev-1.1.2a5-an+fx-delay-5000ms.zip
There is also a way to run the add-on from sources in a temporary profile, although this way it'll be hard to test the behavior at startup. Using the same tool it should be possible to use your normal profile, but I haven't tried it. See Getting started with web-ext if you feel like giving it a try :)
@czukowski man, you're quick!
I already tried about:debugging
but it doesn't persist across restarts.
anyway, 2000ms already solves the issue for me. Thanks!
Regarding noone else stumbled across this bug, I'm wondering what's special about my system. ubuntu studio 14.04 (xcfe4 desktop), firefox 60.0.2 (64-bit), no correlation to other addons
I had a look at the Mozilla ressource and it doesn't look too hard. I'll defintely come back to it in case any other bugs/incompatibilities with other addons arise.
I'll leave this issue open as it's up to you to decide how to proceed. Adding a preferences page to adjust an optional delay is probably too much.
@ronso0 a permission is needed to have preferences page too, which is not a good thing, given the add-on description that actually advertises 'no need to configure anything' and 'no permissions necessary'.
I'll leave this open for now. The issue seems to be stemming from the asynchronous nature of browser tabs when a lot of them are being restored at once, with an added factor of add-on initialization during the browser startup. Putting it all together probably leads to concurrency issues.
For the time being, you're welcome to use one of those development builds, as there are no new features to implement at the moment, and if it comes to more bug fixes, I'll try to address this one too.
Guys, the bug comes back again. Opened tabs all jumble up. Tabs originally at the end, open at the front; front open at the end. Intermittent bug it seems.
@rocketaz could you disable the original add-on and try install it from one of the links above? They are development builds adding delays from 50 to 5000ms before initializing the add-on functions. If one of those helped, please let me know at what delay.
@czukowski I think I could have found the way to reproduce the reversed tab issue. With Tab Control enabled. In 'Show All Bookmarks', open All in Tabs, on selected bookmarks. All opened tabs will be reversed. While disable Tab Control, you'll see all tab opened in order.
@rocketaz thanks, I'll see what I can do. Meanwhile try using one of the versions above with delayed initialization to remedy the issue on startup and see if it helps.
While I had no issues lately (Thanks!) I'm wondering if the startup delay may also be applied when (re)opening stored session windows with multiple tabs? Right now, I work around the previous issue by manually disabling TabControl, open stored session window (wait for all tabs to show up), then re-enable TabControl.
@ronso0 sure, I thought that's what you were doing all along, are there any issues with that? In my case stored sessions reopen just fine, although I rarely have more than 20 tabs open.
Regarding noone else stumbled across this bug, I'm wondering what's special about my system. ubuntu studio 14.04 (xcfe4 desktop), firefox 60.0.2 (64-bit), no correlation to other addons
I had been living with this issue using Debian stable, and a while ago got fed up with it and disabled the plugin on all my accounts. Or so I thought, just found one I must have missed and got annoyed by the tab shuffle on restart again. What with being forced to use Chrome at work I've become more or less accustomed to the same stupid default tab open/close behavior, but I'd love to have an option again someday.
@czukowski Sorry for the long delay, and for being unclear. I referred to opening additional windows via session restore adddon. I see that -if it's possible at all- asked too much to work around that FF bug with your addon. Otoh would it be possible to add a keyboard shortcut to toggle TabControl?
@mmaney have you, per chance, tried any of the development builds with add-on startup delay? There are multiple versions with different delays, I think the optimum value should be around 1 second (1000 ms).
tab_control_dev-1.1.2a7-an+fx-delay-1000ms.zip
If it helps, I'm inclined to adding the delay to the official version, even though it 'kinda' solves just one of the use cases (the others being opening many tabs from the library or using other add-ons).
@ronso0 could you link that addon you're using?
Adding a keyboard shortcut seems to be possible, if it will work without requesting any permissions, I'll add it.
:+1: I use Tab Session Manager by sienori and it's working great.
@ronso0 the version with a keyboard shortcut is now released on AMO.
Meanwhile, would you like to test this development version*? I've come up with an improvement that whenever a new window is open, Tab Control will wait for a short while for its tabs to settle and only then will it have any effect on them. That should leave enough opportunity for add-ons like Tab Session Manager to manage tabs without interference. It may also solve the issue of tabs being mixed up during the initial startup, although since I cannot reproduce that on my computer, I couldn't really verify it.
tab_control_dev-1.1.3-an+fx.zip
Thanks for working on the issue!
Did a quick test with tab_control_dev-1.1.3-an+fx.zip
and it works great,
all tabs are in previous order:
Though, I had one of your dev versions 1.1.2 with delay installed, so 1.1.3 just replaced that.
Good, because 1.1.3 does not have any initial delay (2s working for you previously), and the current improvement seems to be working with only 0.5s delay after new window open.
I'll review the change once more and test it to make sure I haven't broken anything by it and then I'll release it.
Version 1.1.3 has been published.
I'm back to annoy you :) unfortunately, when the CPU load is above usual, the tabs are mixed up again. Seems like the 0.5s delay doesn't suffice (for me) then.
the version with a keyboard shortcut is now released on AMO
I won't find the time to comple the addon myself with a longer delay, so I'd rather use the shortcut. What's the shortcut? I didn't find the info on AMO
hi @ronso0 :)
For the hotkey, you'll need to pick one you like and register it in Firefox yourself, there's no default value. Go to Add-ons, click a button that looks like this: ⚙️⮟ (with the cog symbol) there and select the menu item that says Manage add-on hotkeys.
How much loaded does your CPU get? The current delay is 0.5s since new window open and if there is any tabs activity within that period, it gets prolonged by another 0.5s, repeatedly, if needed. My idea was that with this approach, half a second should be plenty, right?
Go to Add-ons, click a button that looks like this: gear⮟ (with the cog symbol) there and select the menu item that says Manage add-on hotkeys.
Great, I wasn't aware of that feature. Thx!
I didn't measure the CPU load, I just assumed this being the cause, because I had flash videos and another extensive app running.
...it gets prolonged by another 0.5s, repeatedly, if needed
Okay, so for some reason this appareantly didn't work on my machine. I'm fine with the shortcut for now. I need to put the tab/CPU investigation on my ToDo until I find time.
@ronso0 for now I've only been able to reproduce the issue with the Tab Session Manager add-on and verify that the fix in v1.1.3 worked on my computer. Did you perceive any lagging in Firefox when restoring tabs during high CPU load? I'd say it must have been visible if the interval between any of the restored tabs exceeded half a second. I'll try to simulate high load on my computer and see if I can reproduce the issue.
Did you perceive any lagging in Firefox when restoring tabs during high CPU load?
To reproduce, I just started Mixxx during a regular (low load) FF session and restored a window with Tab Session Manager at the same time: some tabs were moved like the original issue describes. FF tabs (content) are restored only if I focus them, so I can only confirm an expected, small lag like with all other apps.
@ronso0 sorry for the late reply. I tried to run some CPU stress testing that causes 100% load and restore windows with Tab Session Manager during that, but in all cases the tabs order turned out correctly, so I couldn't reproduce the issue for now.
It may be that a browser can't open tabs within half a second between each other under high load, but I'm afraid if the delay is increased, it might cause noticeable lag between the tabs finished ~opening~ being added to the window and the add-on function kicking in.
Do you still see the issue regularly under high load? Would you say that some of the tabs open in correct order and some don't, or all tabs are in wrong order?
sorry for the late reply
please, don't mind :) It's just I notice a few tabs being pushed around now and then, no big deal. I see the compromise you'd have to make with a longer wait period (the lag). If no one else is affected it's fine. Thank you! In case it bothers me I'll simply install the dev version you supplied.
Thanks again!
@ronso0 if you'd like, here are some new development versions for testing:
tab_control_dev-1.1.3.1-an+fx-flat-delay-750ms.zip - this one is just like the current official, but with a bit longer delay: 750 ms delay between tabs tab_control_dev-1.1.3.3-an+fx-adaptive-attenuated-delay-750-to-250ms.zip - this one starts with 750 ms delay and with each new tab added it gradually reduces the delay to 250 ms, but only if the reduced delay would not be less than the amount of time taken to add last tab to the window.
I've tried some measuring when using Tabs Session Manager and found out that it usually takes much more time to add the 1st tab to a new window (in my case slightly more than 100ms) than the others. Other tabs were all < 10 ms between each other. This has led me to the idea with the 2nd approach above. You may see the debug output in the browser console (activated with Ctrl+Alt+Shift+I), it will tell the time elapsed since the previous open tab when lock is refreshed by opening another tab.
@czukowski Thank you, I'll test those soonish.
To reproduce:
Linux Firefox 59.0.2 (64-bit) My tabs are restored properly if I deactivate tab-control before quitting FF, then re-activate it after next start. Maybe it helps to delay tab-control until FF has restored all tabs & windows.