multi-account-containers
multi-account-containers copied to clipboard
Disabling and re-enabling the add-on resets the config
- 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
- Add a new container
- Disable the add-on
- Enable the add-on
The new container has disappeared.
Notes
This is a horrible issue. Due to https://github.com/mozilla/multi-account-containers/issues/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.
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...
Same happens if firefox crashes and wants to restore the last session via about:sessionrestore at next startup
Same
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.
Now with armagadd-on-2.0 this issue affected many people. Any plans to change the current behaviour?
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.
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.
~~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…
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.
Nevermind my previous comment: 66.0.4 did reset my containers…
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!
if this issue is difficult to fix, there should at least be an export/import for the custom permanent containers.
@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.
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?
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.)
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.
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.
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? 🤨
Is there anyone at all working on this glaring bug?
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.
The bug is still there. I just lost my settings; wondering why and searching the internet I landed on this, still open after four years issue.
I also ended up with this issue when trying to diagnose an issue with webpage styling (which was traced back to https://github.com/mozilla/contain-facebook/issues/861).
Please fix this asap. Till then, is there a way to manually save the config such that it can be re-imported later if the config is reset?
@architchandra #1533 is ready since almost 3 years now... :confused:
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? 🤔