Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Disabling extension closes all container tabs without warning #864

Open
wanderview opened this issue Sep 26, 2017 · 16 comments

Comments

Projects
None yet
8 participants
@wanderview
Copy link

commented Sep 26, 2017

I disabled the extension in about:addons. This closed all my container tabs without warning. Re-enabling the extension did not restore the tabs. This was a bit unexpected and inconvenient.

@jonathanKingston

This comment has been minimized.

Copy link
Member

commented Sep 26, 2017

This would require changing platform itself when the last contextualIdentities extension is removed. Currently I think we warn when we remove containers in about:preferences but hitting remove doesn't doe that here or disable etc. (this might actually be a dupe with a platform bug, will check).

@grahamperrin

This comment has been minimized.

Copy link

commented Oct 3, 2017

… disabled the extension in about:addons. This closed all my container tabs …

Not reproducible here with Multi-Account Containers 4.0.3 added to a clean profile of Firefox 56.0 (64-bit) on FreeBSD-CURRENT. Neither disabling nor removing the extension caused disappearance of the one page that I had contained.

After removing the extension I quit then relaunched Firefox, restored the previous session then non-extended Firefox presented the page, contained. All good.

@wanderview

This comment has been minimized.

Copy link
Author

commented Oct 3, 2017

My tabs were pinned container tabs on FF57. Not sure if that difference matters.

@wanderview

This comment has been minimized.

Copy link
Author

commented Oct 4, 2017

Also, I had deleted all the default containers and created these containers from scratch. Perhaps if you have the default containers they are not reset?

@grahamperrin

This comment has been minimized.

Copy link

commented Oct 4, 2017

… pinned container tabs on FF57. Not sure if that difference matters.

I can't comment on 57 but for what it's worth, with removal:

created a test profile, installed and removed the addon, no browser restart required and all pinned tabs are still there.

@grahamperrin

This comment has been minimized.

Copy link

commented Oct 5, 2017

https://blog.mozilla.org/tanvi/2017/10/03/update-firefox-containers/#comment-36315 (2017-10-04) mentions a bug fix relating to loss of hidden containers. Did that fix occur after the 2017-09-26 opening of this issue? I wonder.

Also @wanderview please: what's your platform? And can you recall the exact version or build of 57 that was in use when this issue was reported?

I might have read, somewhere, that PPA provision of builds of e.g. firefox-trunk for Linux sometimes lags a little behind what's built in other areas.

@jonathanKingston

This comment has been minimized.

Copy link
Member

commented Oct 9, 2017

Also, I had deleted all the default containers and created these containers from scratch. Perhaps if you have the default containers they are not reset?

57+ uses native central behaviour on deleting containers and resetting them.

The current algo for this is here:
http://searchfox.org/mozilla-central/source/toolkit/components/contextualidentity/ContextualIdentityService.jsm#124

Given the two main places for this experience are:

  • Disabling an addon in about:addons
  • Disabling an addon in about:preferences

We could probably just put warnings there for now, however I will speak with the web extension folk to see if there is a better way. about:addons is likely more of a priority as the intent in about:preferences is to disable containers anyway.

@grahamperrin

This comment has been minimized.

Copy link

commented Feb 21, 2018

Drive-by thought: if Firefox Sync will cause uninstallation of all containers-related extensions from a second or nth computer, then should the user be warned at each computer?

@stoically

This comment has been minimized.

Copy link
Member

commented Mar 12, 2018

Not sure if that's feasible/wanted, but might it be an alternative to reset containers only if the last container Add-on is removed instead of just disabled?

@3j9fkyahunqoxwqu

This comment has been minimized.

Copy link

commented May 4, 2019

Hi
i don't know about addon developing but may be a way to backup/restore containers also be a great workaround for this issue if it is hard to fix or impossible due to APIs or ...
Thanks

@codingchristoff

This comment has been minimized.

Copy link

commented May 9, 2019

Recently I started FireFox on both my Laptop and Desktop and both started in what seemed like a fresh install. All add-ons had been disabled. When I investigated it stated they were out of date and unsupported. When I closed FF and re-opened my add ons came back however it seemed they had all reset to default.

The containers is by far the most annoying as all my custom containers have now been lost.

Expected Result:

Disabled add-ons should not delete config files by default. Allowing users to restore their custom settings.

@grahamperrin

This comment has been minimized.

Copy link

commented May 12, 2019

Enable Built-in Containers Feature
https://addons.mozilla.org/addon/enable-builtin-containers/

… can be useful to keep the built-in containers on and avoid container data loss.

@dannycolin

This comment has been minimized.

Copy link

commented May 12, 2019

@grahamperrin it wouldn't have help with the certificate problem since all addons were disabled automatically.

It'd be better to open an issue on bugzilla.mozilla.org asking the devs to make sure that privacy.userContext.enabled can't be reset by Firefox if it has been set to true manually or by an extension that is still installed even if it's disabled.

@jonathanKingston did you have any luck contacting the devs?

@grahamperrin

This comment has been minimized.

Copy link

commented May 26, 2019

wouldn't have help with the certificate problem

True, but it's an extension that might help to minimise the future possibility of a user shooting himself or herself in the foot.

… asking the devs to make sure that privacy.userContext.enabled can't be reset …

I should encourage a more fundamental re-think. Essentially:

  • disabling the containers feature of Firefox must not delete container-related data.
@dannycolin

This comment has been minimized.

Copy link

commented May 26, 2019

I should encourage a more fundamental re-think. Essentially:

* disabling the containers feature of Firefox must not delete container-related data.

@grahamperrin FYI, https://bugzilla.mozilla.org/show_bug.cgi?id=1549204

@grahamperrin

This comment has been minimized.

Copy link

commented May 26, 2019

Thanks, I began following that bug a couple of weeks ago but hadn't digested it. I'm with comment 3,

… clearing all container data when flipping this pref is not a good idea …

PS it wasn't armagadd-on 2.0 that swayed me; I always thought (but maybe never wrote) that loss is not a good idea.

In the same way that bookmarks are reasonably well protected against accidental mass deletion (like, actively aiming to delete everything is extraordinary), so container data should be well protected.

Irrespective of whether they're enabled, containers are an integral feature of Firefox.

Removing all bookmark-oriented add-ons does not lead to a warning about removal of bookmarks; removing all container-oriented add-ons should must not lead to removal of containers.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.