Disabling and re-enabling the add-on resets the config

[cjkent]

• Is "Firefox will: Never remember history" in the Firefox Preferences/Options under "Privacy & Security > History" selected? No
• Are you using Firefox in a Private Window? No
• Can you see a grayed out but ticked Checkbox with the description "Enable Container Tabs" in the Firefox Preferences/Options under "Tabs"? No
• Multi-Account Containers Version: 6.0.0
• Operating System + Version: macOS 10.13.5
• Firefox Version: 61.0.1
• Other installed Add-ons + Version + Enabled/Disabled-Status:

Name	Version	Enabled	ID
Firefox Multi-Account Containers	6.0.0	true	@testpilot-containers
New Tab Override	14.0.2	true	[email protected]
Stylus	1.4.13	true	{7a7a4a92-a2a0-41d1-9fd7-1e92480d612d}
uBlock Origin	1.16.12	true	[email protected]
Vimium	1.63.3	true	{d7742d87-e61d-4b78-b8a1-b469842139fa}
Blank New Tab	2.0.0	false	blanknewtab@goodthings
Context Search Origin	2.1	false	{e040cf12-0537-4265-8ce0-ee195356ed60}
OneLogin for Firefox	3.4.2	false	[email protected]

Actual behavior

Container tabs configuration is reset after disabling and re-enabling the add-on

Expected behavior

Configuration is restored when re-enabling the add-on

Steps to reproduce

1. Add a new container
2. Disable the add-on
3. Enable the add-on

The new container has disappeared.

Notes

This is a horrible issue. Due to #1227 I spent a lot of effort manually hacking my config. I disabled the add-on when I was trying to diagnose an (unrelated) problem with Firefox. And when I re-enabled it my config was reset to the default.

[AdKiller]

same problem here with Firefox ESR 60. spent a lot of time configuring containers, disabled the addon temporarily to troubleshoot something and when enabled, poof everything was gone...

[HeikoAdams]

Same happens if firefox crashes and wants to restore the last session via about:sessionrestore at next startup

[qsantos]

Same

[ZombieAlex]

This is actually even worse than described. Disabling and re-enabling removes all your custom containers but does not reset @testpilot-containers/storage.js with all site assignments.

storage.js pairs domains with containers by a container ID number rather than the container's name.

The two issues combined mean that after I recreated my custom containers in a different order than they were before I'd disabled the extension, I now have domains automatically loading in the wrong container.

I'd prefer if disabling didn't remove custom containers at all. But if that's not fixable for some reason, it should definitely reset storage.js and domain assignments as well.

[Tithen-Firion]

Now with armagadd-on-2.0 this issue affected many people. Any plans to change the current behaviour?

[AdKiller]

I have a creeping feeling that after today's sh*t show with certificate signing that disabled all Firefox add-ons across all platforms, the settings of this addon will be reset again. (thankfully I have backups that I can dig out).
https://www.ghacks.net/2019/05/04/your-firefox-extensions-are-all-disabled-thats-a-bug/

Firefox containers is the best feature that Mozilla has created in a long time, and the only thing that sets it apart from Google Chrome, for now...

+ Improving Firefox containers and fixing this issue should be top priority.

[quietlystorming]

I have a creeping feeling that after today's sh*t show with certificate signing that disabled all Firefox add-ons across all platforms, the settings of this addon will be reset again.

@AdKiller You were right.

[qsantos]

When I encountered the problem, I feared that the usual proposed solution, which implied reinstalling the addons, would wipe out my containers (again). However, I managed to reactivate my addons using another approach (note that I needed to set devtools.chrome.enabled to true in about:config to access to the browser console prompt).

Nevermind, hotfix 66.0.4 did reset my containers…

[groovecoder]

See also https://bugzilla.mozilla.org/show_bug.cgi?id=1549204 for the bugzilla bug, and I'm going to start closing duplicate issues of this one.

[qsantos]

Nevermind my previous comment: 66.0.4 did reset my containers…

[thefireinyourflies]

experienced this bug yesterday and reproduced again today with a set of test pages. when troubleshooting another third-party add-on, i disabled everything else including multi-account-containers. in so doing all contained tabs immediately closed without warning and are nowhere to be found in history to re-open! re-enabling the add-on does not restore the tabs. i am logged into FF account. what can be done to locate those tabs?? and please fix!

[AdKiller]

if this issue is difficult to fix, there should at least be an export/import for the custom permanent containers.

[jonlm]

@thefireinyourflies See the bugzilla link. When the extension is disabled there is some javascript that actively deletes all container tabs and custom container data. They're gone for good unless you happen to have a backup of your entire profile from when the data was valid. Yes, this is a horrible design that needs to be fixed, and seemingly will be.

[thefireinyourflies]

thanks for the info @jonlm, i had see that bugzilla but i am not a developer and it did not hit me what part of the report mentioned closing open container tabs. i see that script snippet now mentioning "this.closeContainerTabs( )" function

fortunately i do have a usable file level backup of my FF profile i was able to recover, would you or anyone else have guidance what to do with it to get my tabs back up? do i just replace the whole profile in AppData (using Win10) or can i pull out specific files to copy into my current profile folder? do i create a new one with FF manager and copy the date into that one? does FF account and sync play a part in containers at all?

[garretwilson]

As noted in #1405, when Mozilla disabled all my plugins because of the certificate SNAFU, suddenly all my containers are gone.

@groovecoder indicated that I should comment and/or vote to get this fixed. So I hereby vote: Firefox, please don't erase my data and delete my configuration. (We have to vote on something like that? I would have thought it would be a critical top-priority bug.)

[dakujem]

It's not the addon only - in case one disables the option privacy.userContext.enabled, the customization settings are lost. Disabling the addon disables this option too, so the settings are lost as well.

[06000208]

No other firefox extension to my knowledge has this behavior, where when disabled, all configuration and settings are lost... so I had no reason to expect this to be the case when I temporarily disabled the addon.

Wouldn't it be more logical if container data is removed when all container addons are removed, rather than as soon as all container addons are disabled, if I understand this accurately?

This issue causes seemingly unrecoverable loss of user data without backups, so as groovecoder indicated, I am commenting to direct attention to it.

[Synetech]

See also https://bugzilla.mozilla.org/show_bug.cgi?id=1549204 for the bugzilla bug, and I'm going to start closing duplicate issues of this one.

Wouldn't it be easier to just fix it? Or at the very least provide an import/export function? 🤨

[OsakaWebbie]

Is there anyone at all working on this glaring bug?

[groovecoder]

This came up again in the context of the "Refresh Firefox" feature, which triggers this unexpectedly. I'm going to try to get some help here.

[Minigugus]

@architchandra #1533 is ready since almost 3 years now... 😕

[Synetech]

Is this extension by a third-party (who might not be working on it anymore)? I thought it was by Mozilla themselves; are they too busy working on the main browser. 🤨 Are they building this feature into the browser so that the addon is unnecessary? 🤔

[Ali-RS]

Got hit by this issue as well, please fix it!

[huksley]

I have experienced the same problem - lost rules and custom container names when temporarily disabling this addon. I have Firefox Sync enabled, but it does not help. Is there any way to restore settings?

[PrissyPineapple]

For the love of god, can someone at the absolute minimum create a warning on the Add-on page that this is a thing that happens?

This has been going on for five years. One would think there would be something for such a huge issue.

[nl-brett-stime]

For the love of god, can someone at the absolute minimum create a warning on the Add-on page that this is a thing that happens?

This has been going on for five years. One would think there would be something for such a huge issue.

I'm sure a pull request would be welcome 🤷 .

[06000208]

I'm sure a pull request would be welcome 🤷 .

@nl-brett-stime This can't be fixed by a PR to the extension's code, afaik. It's a longstanding issue in firefox where if there are no container-using extensions, all container data is immediately wiped. Refer to this bug on bugzilla.

This has been going on for five years. One would think there would be something for such a huge issue.

The priority on the above bugzilla issue seems to be mislabeled as P3, whereas I believe it deserves P2 (being unable to disable certain extensions is severe impairment of functionality) or P1 (as it causes data loss) due to this list, but someone was working on a fix back in 2022

[findingcoins]

This just happened to me today. What an unpleasant surprise.

I was attempting to diagnose an issue I'm having on a particular website; naturally they suggest trying a private window with all addons disabled. This extension doesn't even run in private windows, so I don't know why this should have happened as a result of disabling it in an private window.

What a nuisance. Maybe I should just go with separate Firefox profiles, if this extension can be rendered useless so easily, and it hasn't been fixed after five years.

[rafeerahman]

Curious to see if this bug is still reproducible for anyone?

[OsakaWebbie]

Curious to see if this bug is still reproducible for anyone?

I decided to try it for you after making sure I had a backup of my profile. But when I looked at my add-ons, I was surprised to discover that there is apparently no extension for basic containers anymore. I disabled all extensions (including a few that involve containers in some fashion: Container Home Pages, Facebook Container, and Open links in a container), and my containers continued to operate. So I guess it's fixed for me, at least.

[blakegonzales]

Curious to see if this bug is still reproducible for anyone?

I no longer have the issue anymore! After disabling and re-enabling the container add-on, all of my containers and site lists are still there. Nice.

[dannycolin]

Fixed by bz#1549204