simple-tab-groups
simple-tab-groups copied to clipboard
Tab duplicates in group with containers
I have a specific group that I use for work. Whenever I close the browser and re-open it all the tabs in said group are duplicated. I don't know if this is regular behaviour and I'm just missing a setting or if it's a bug.
I have the same bug. I know that this happened once some time ago. So it seems this was reintroduced in a recent update. Sometime these tabs also get duplicated further once you select them.
Happens for me as well for a while now.
I have the same issue too. This happened before but it was resolved. It seems like turning off "Open previous windows and tabs" fixes it but ya know, why would anyone turn that off?
Edit: I reverted back to v4.7 and it's working fine.
Hi @Drive4ik This issue is really annoying. Do you have any ideas/plans to fix it? I can help if needed - if you guide me in the right direction :) Thanks!
https://github.com/Drive4ik/simple-tab-groups/issues/891#issue-1070046959
Whenever I close the browser and re-open it all the tabs in said group are duplicated.
Which operating system?
Which version of the extension?
Are other extensions enabled? If so: please list them, and their versions.
If you exit or quit (instead of closing the final window), is behaviour the same?
Does duplication of all tabs, in all windows, begin immediately after Firefox restores the windows?
Or, does duplication of a tab occur only after you click to load the tab?
After Firefox restores windows: if you open a new window and then load a group into the window, is there duplication of the initially loaded tab?
I am running Linux (I've had the problem with at least 2 different distros: Solus and PopOS).
Version of the extension is: 4.7.2.1 updated March 14 2022.
I have not tested whether or not Exiting Firefox or closing the last window changes behaviour.
Duplication does not begin immediately and it doesn't seem to begin when I load a group. I almost never load the same group in my first window, I always open the group in a new window.
Lately I still have the problem, but I'm not sure when it happens. I tried closing and exiting real quick and they didn't get duplicated, but a different group had been duplicated in the past. Will try to test out wha you just mentioned.
I am running Windows 10.
Version of extension is 4.7.2.1
I disabled all other extensions except Multi-Account Containers (because otherwise I can't test this with containers). Multi-Account Containers is on version 8.0.6, incidentally.
The problem happens for me when I open up a Tab Group in a new window, where that Tab Group previously had one or more tabs opened in a container. Every tab that was opened in a container will become duplicated into a tab that's not in a container (i.e. you end up the same site being opened in two tabs, one in the container and one in a normal tab), immediately. The behavior only happens the first time I open up a Tab Group in a new window during that session. If I close this secondary Tab Group window (without quitting Firefox or closing the last window), and open this Tab Group in a new window again, it does not duplicate any tabs.
If I close this secondary Tab Group window (leaving one window/tab group left) then Quit Firefox, when I reopen Firefox and reopen this Tab Group in a new window, the tab does not get duplicated, but is instead not in a container (i.e. it just opens the tab without a container).
If I don't close the secondary Tab Group window (leaving two windows/tab groups open), then Quit Firefox, when I reopen Firefox it works as expected (tabs in both tab groups are not duplicated, are in containers if they were before quitting).
It does not generally happen to me with the first window when I first open up Firefox. i.e. If I had tabs opened in containers in the last window, the next time I open up Firefox, most of the time it will not duplicate the container tabs into normal tabs. I think I may have experienced duplication in the past with older versions of the extension, but I'm not too sure on this. It does not seem to be happening now during testing, in any case.
Would it be ok to post a video of the issue? I can upload it as private to my youtube channel. I have managed to reproduce the problem fairly well, but it's a bit of a long process.
@AlienTux I recorded this a few days ago, hesitated before sharing only because I wasn't sure whether I have the same issue. Now I'm fairly certain that this is comparable to what you encounter:
https://user-images.githubusercontent.com/192271/158793745-2127dfdf-0492-48e3-bcd7-bcb7c9231a85.mp4
- Simple Tab Groups 4.7.2.1
- Firefox Multi-Account Containers 8.0.6
- Firefox 98
- FreeBSD 14.0-CURRENT
% pkg info -x firefox
firefox-98.0_2,2
% pkg -vv | grep -e url -e enabled
url : "http://pkg0.bme.freebsd.org/FreeBSD:14:amd64/latest",
enabled : yes,
url : "https://alpha.pkgbase.live/current/FreeBSD:14:amd64/latest",
enabled : no,
url : "file:///usr/local/poudriere/data/packages/main-default",
enabled : yes,
% freebsd-version -kru
14.0-CURRENT
14.0-CURRENT
14.0-CURRENT
% uname -aKU
FreeBSD mowa219-gjp4-8570p-freebsd 14.0-CURRENT FreeBSD 14.0-CURRENT #6 main-n253776-d5ad1713cc3-dirty: Mon Mar 14 22:38:12 GMT 2022 root@mowa219-gjp4-8570p-freebsd:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODE
I'm reasonably certain that Mozilla's Firefox Multi-Account Containers is involved, because (as far as I can tell) the issue is never encountered with tabs for Mozilla pages for extensions, for example:
- https://addons.mozilla.org/addon/media-bias-fact-check/ (non-localised – expect a redirect)
– and by Mozilla's design, its extension is incapable of handling pages such as those.
tl;dr we should probably never find automatic containment of an AMO page.
An essential question:
- is this issue with an extension, or does combined use of extensions reveal a bug in Firefox?
https://github.com/Drive4ik/simple-tab-groups/issues/891#issuecomment-1009840394
… Edit: I reverted back to v4.7 and it's working fine.
I also experimented with reversion of various extensions, spent some hours doing so. Ultimately I failed to arrive at a consistently working combination.
@harvy2004 please, is inferior 4.7 a consistently good workaround for you?
From my own experience, at the time of writing I suspect an issue with Firefox.
I'll draw attention in a Mozilla area, maybe aim for one of the people who helped with last year's issue #779. Postscript: done, https://matrix.to/#/!CuzZVoCbeoDHsxMCVJ:mozilla.org/$GBNfOESZF-I0WvXTAVDW9joEbp17Z5NFg9RcsB2KGPs?via=mozilla.org&via=humanoids.be&via=matrix.org
@grahamperrin Yes, so I am currently running
- FF 91.7.1esr (64-bit)
- version 4.7 of the extension
- Windows 10 latest
and it works fine. I can try it with the general release of FF and see if it causes any issues but I suspect not. Also every time I've upgraded FF (admittedly on the ESR track) the extenstion still works.
… after a crash or reboot, so perhaps not the same issue,
I suspect a different issue.
… I don't have the multi-account container extension.
This strengthens my suspicion that yours is a different issue.
Is #347 a better fit? If so, you can leave a comment there (and remove the one above). Thanks.
https://github.com/Drive4ik/simple-tab-groups/issues/891#issuecomment-1070806518
FF 91.7.1esr (64-bit)
Thanks @harvy2004
The two (non-linked) comments below remind me that I probably first found symptoms in December 2021; the screenshot on 2021-12-24 was of 95.0.2 (visible at top left).
https://github.com/piroor/treestyletab/issues/2845#issuecomment-1000836106
https://github.com/piroor/treestyletab/issues/2845#issuecomment-1000880498
I might have attempted to diagnose things for myself (without posting anywhere) for two or three weeks before Christmas. (I should check Matrix logs etc. to tell, more exactly, when the issue began for me. I might edit details into this comment.)
Timeline for update to 95 on (Tier-3) FreeBSD: https://cgit.freebsd.org/ports/log/www/firefox?qt=grep&q=update+to+95. Whilst I did not keep a record of when I gained each of the updates, the timeline is broadly consistent with my recollection of finding symptoms during December.
Opening post https://github.com/Drive4ik/simple-tab-groups/issues/891#issue-1070046959 (2021-12-02)
@AlienTux please, can you tell (or guess) which version of Firefox was in use, on Pop!_OS or Solus, when you first found symptoms?
Timeline for Tier-1 releases:
- 2021-11-02 https://www.mozilla.org/firefox/94.0/releasenotes/
- 2021-11-04 https://www.mozilla.org/firefox/94.0.1/releasenotes/
- 2021-11-22 https://www.mozilla.org/firefox/94.0.2/releasenotes/
- 2021-12-07 https://www.mozilla.org/firefox/95.0/releasenotes/
- 2021-12-16 https://www.mozilla.org/firefox/95.0.1/releasenotes/
- 2021-12-19 https://www.mozilla.org/firefox/95.0.2/releasenotes/.
Ok, apparently the problem actually is on Firefox's side. Yesterday I made a log and managed to reproduce the problem. Today, after upgrading to Firefox 98.0.1, it's working properly.
Just to answer the previous question @grahamperrin I don't remember which version of Firefox it was but it had been happening for quite a while (maybe a month or two ago I switched from Solus to Pop!_OS) and I always updated to the latest version. I tried it both in Firefox and Waterfox to the same results.
Today tho... It's working properly.
Here's my apt's upgrade log in case it's useful:
Start-Date: 2022-03-17 10:58:14
Commandline: packagekit role='update-packages'
Requested-By: kurt (1000)
Upgrade: firefox-locale-ar:amd64 (98.0+build3-0ubuntu0.21.10.2, 98.0.1+build2-0ubuntu0.21.10.1), firefox-locale-de:amd64 (98.0+build3-0ubuntu0.21.10.2, 98.0.1+build2-0ubuntu0.21.10.1), firefox-locale-en:amd64 (98.0+build3-0ubuntu0.21.10.2, 98.0.1+build2-0ubuntu0.21.10.1), firefox-locale-es:amd64 (98.0+build3-0ubuntu0.21.10.2, 98.0.1+build2-0ubuntu0.21.10.1), firefox-locale-fr:amd64 (98.0+build3-0ubuntu0.21.10.2, 98.0.1+build2-0ubuntu0.21.10.1), firefox-locale-it:amd64 (98.0+build3-0ubuntu0.21.10.2, 98.0.1+build2-0ubuntu0.21.10.1), firefox-locale-ja:amd64 (98.0+build3-0ubuntu0.21.10.2, 98.0.1+build2-0ubuntu0.21.10.1), firefox-locale-pt:amd64 (98.0+build3-0ubuntu0.21.10.2, 98.0.1+build2-0ubuntu0.21.10.1), firefox-locale-ru:amd64 (98.0+build3-0ubuntu0.21.10.2, 98.0.1+build2-0ubuntu0.21.10.1), bind9-host:amd64 (1:9.16.15-1ubuntu1.1, 1:9.16.15-1ubuntu1.2), bind9-dnsutils:amd64 (1:9.16.15-1ubuntu1.1, 1:9.16.15-1ubuntu1.2), bind9-libs:amd64 (1:9.16.15-1ubuntu1.1, 1:9.16.15-1ubuntu1.2), firefox-locale-zh-hans:amd64 (98.0+build3-0ubuntu0.21.10.2, 98.0.1+build2-0ubuntu0.21.10.1), firefox-locale-zh-hant:amd64 (98.0+build3-0ubuntu0.21.10.2, 98.0.1+build2-0ubuntu0.21.10.1)
End-Date: 2022-03-17 10:58:16
Thanks,
… Today, after upgrading to Firefox 98.0.1, it's working properly. …
Not so, here.
I don't doubt that things appear to be OK for you at the moment, but (based on my own experience with updating, downgrading and so on) you might find that the appearance of a fix is temporary.
% uname -KsU
FreeBSD 1400053 1400053
% grep firefox /var/log/messages
Mar 18 09:45:32 mowa219-gjp4-8570p-freebsd pkg[94269]: firefox upgraded: 98.0_2,2 -> 98.0.1,2
%
Screen recording:
https://user-images.githubusercontent.com/192271/159001349-8ea5d435-f76a-462b-b2e4-2eaacac4a2bc.mp4
Ok, I spoke too soon. Yesterday night I was working and everything seemed nice. Today, after completely shutting down and booting my computer up one of the groups has been duplicated. You were right @grahamperrin .
However, I haven't been able to reproduce the problem. I'm going to spend the weekend trying to reproduce my problem.
I do believe it's a bit differente than yours tho. Looking at your video you get a duplicate tab when you switch to it. My issue is a bit different: sometimes when I restart Firefox/session I get a duplicate of the entire tab group. When I open each tab I briefly do see a duplicate of the tab, but it gets immediately deleted.
As I said, I will try to reproduce the problem during the weekend and upload a video (I've recorded several, but can't reproduce the problem since last Firefox update).
a duplicate tab when you switch to it.
Duplication begins when I load a group into a new window, only if the group was not previously loaded.
There's duplication of the first tab that's loaded (without me clicking), then duplication of any other tab that is clicked, but as far as I can tell:
- duplication occurs only where the non-contained tab is loaded (into an adjacent tab) into a container, by Mozilla's extension.
The tab that was clicked remains empty, non-contained. Like, pre-containment debris.
… shutting down and booting …
In some cases, Firefox-related processes continue to run – invisibly – for some time after a visible quit of the application. For example:
https://user-images.githubusercontent.com/192271/159092794-88676203-dcae-4ce2-ad97-74f01167e3d0.mp4
@AlienTux for troubleshooting purposes, for now, please use htop, or your utility of choice, to ensure that all Firefox-related processes have stopped before shutting down, or restarting, the computer.
(Non-extended Firefox might be relatively tolerant to rushed endings e.g. shutdown -r now or shutdown -p now whilst the application runs. Firefox with some types of extension might be less tolerant.)
https://github.com/Drive4ik/simple-tab-groups/issues/891#issuecomment-1072499313
… The tab that was clicked remains empty, non-contained. Like, pre-containment debris.
Extending that thought: maybe as if the contained status of a tab is not preserved (by Simple Tab Groups) if there is no window to the tab at quit time.
Please try:
- close all windows except one
- in the one remaining window,
about:config fission.autostart- change from
true(the default) tofalse fission.autostart.session- if not locked, set to
false - open a new window
- load a group that you have not previously loaded during the session – specifically, a group that is likely to be bugged by duplication (where a tab is contained)
- trigger the duplication in as many tabs as you like within this window
- de-duplicate, leaving only the contained copy of each previously bugged tab
- close the window
- quit Firefox
- wait a minute or so (long enough to be certain that Firefox is not still invisibly quitting)
- start Firefox
- open a new window
- load the group that you loaded at step (8) during the previous session
- trigger the duplication
– with those two fission preferences disabled, does the trigger work (does the bug persist)? Or are you free from the bug?
So for me fission.autostart.session is locked. Following all your steps aside from setting fission.autostart.session to false still results in tab duplication.
Thank you,
… for me
fission.autostart.sessionis locked. …
Locked to which value?
For me: it's locked to false.
% pkg info -x firefox
firefox-101.0,2
% pkg -vv | grep -e url -e enabled
url : "pkg+http://pkg0.pkt.freebsd.org/FreeBSD:14:amd64/latest",
enabled : yes,
url : "https://alpha.pkgbase.live/current/FreeBSD:14:amd64/latest",
enabled : no,
url : "file:///usr/local/poudriere/data/packages/main-default",
enabled : yes,
% uname -aKU
FreeBSD mowa219-gjp4-8570p-freebsd 14.0-CURRENT FreeBSD 14.0-CURRENT #12 main-n255769-f16e38162c7-dirty: Tue May 24 11:48:57 BST 2022 root@mowa219-gjp4-8570p-freebsd:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG amd64 1400059 1400059
%
Early indications are that (for me) there's a consistent workaround.
I have started Firefox more than once, loaded various groups (with auto-contained tabs) that were previously bugged, at the time of writing I can no longer reproduce the bug.
Whether the two fission preferences are only part of the apparent workaround, I don't know.
For me its also locked to false. But I am still getting duplicated tabs.
Firefox 100.0.2 on Windows.
Thanks again.
Confused face, only because for me (with the port of Firefox 101.0 on Tier-3 bleeding edge FreeBSD 14.0-CURRENT) the early indications are so consistently positive. I'll continue to test, aggressively.
I wonder whether things will be different for a user of 101.0 on a Tier-1 platform.
I have fission.autostart set to false. 'fission.autostart.session' is locked and set to false as well.
Firefox 100.0.2 on Linux (Pop OS installed via deb package).
I shut down firefox (via Quit in the menu. Didn't shut down my laptop), continued working, opened it up again a couple of times and it was fine. I shut down my laptop and the following day (today) all the windows that I opened that I have set up as Always open tabs in container (see screenshot) contained duplicates.
Here's a screenshot of the manager: https://i.imgur.com/ZlNzaur.png. You can see in (1) the tab without the container and in (2) where the duplication starts. All the tabs were duplicated.
EDIT: Shut down laptop and turned it back on again. The groups that I had not previously opened didn't duplicate. The groups that I did open duplicate (one even tripled).
Thanks,
… set up as
Always open tabs in container(see screenshot) …
I never use that feature.
Here:
… I'll continue to test, aggressively. …
– since I changed the Fission preference, around five days ago, I have been unable to reproduce the issue.
Almost December 21. I have noticed it for a long time now. All groups that have been active when closing FF (107 on Windows 10 21H2 and many versions of FF before this one), duplicate the containerized tabs outside of containers.
I never took the time to see if this was reported and now that I do, it seems a feature, not a bug. :-) (Try to keep smiling).
So once agian, I was able to reproduce the problem as follows:
- Go to manage groups and close all duplicates outside of containers in all groups (tabs are inactive)
- Open a containerized tab in a group with multiple containerized tabs (now at least one tab is active)
- Close Firefox. Warning of closing multiple tabs is on in my configuration
- Reopen Firefox
- Notice the containerized tabs in the formerly active group have duplicated
- Notice the containerized tabs in formerly unused groups have not duplicated
I use 18 groups as a working standard, used to have about 200 to 300 tabs open. Since containers arrived, I see around 500 opened tabs. When I use the close duplicates plugin (which I don't like because you never know in which groups it will close them), a little less than 300 are left.
My preferred way of working is having known website in specific containers and leave the rest open to spread inaccurate data for the AI systems to be screwed up with my garbage. Garbage in, garbage out. That is one good reason why I do not want to open every page in a container. Not even sure if it would work.
I am using your great plugin for efficiency. My FF is my memory as to all the different things that need my attention. Having to go about the duplicates unfortunately is a bit of a strain on that use. But the addon is still the A-number one top best addon I use. I just hope you'll find out how to close the newly created url's that already live inside a container.
I just want to comment that I was also experiencing this. The Ctrl+Shift+Q method of closing Firefox has so far prevented the issue, but there is definitely a bug here that should be addressed.