1373244 - Dedicated profiles per channel

Status: RESOLVED WONTFIX

(Toolkit :: Startup and Profile System, enhancement)

Comment 1

[Benjamin Smedberg]

Romain since you filed this bug are you going to triage it and set priority? I'm technically the triage owner for this component but I don't manage the engineering team that would work on this.

Comment 2

[Romain Testard [:RT]]

(In reply to Benjamin Smedberg [:bsmedberg] from comment #1)
> Romain since you filed this bug are you going to triage it and set priority?
> I'm technically the triage owner for this component but I don't manage the
> engineering team that would work on this.

Yes, I'm on parental leave until end of next week but I'll scope this out when I'm back (We can learn from what was done with dev edition, Tom had a patch we may be able to re-use on bug 1355204) to then work out tech feasibility and set the priority.

Comment 3

[Dave Townsend [:mossop]]

Please see https://groups.google.com/forum/#!topic/mozilla.dev.platform/-caAmk_ijnY where I proposed a way to achieve this.

Comment 4

[Jeff Griffiths (:canuckistani) (:⚡︎)]

I want to bump this a little in priority. We just ran into another case where this caused a problem, this time in the different preferences set by system add-ons controlling e10s multi configuration and deployment on different channels. tl;dr, in some cases users switching between Nightly and Release did not get a working multi configuration in some cases. The impacted group of people here is very low but includes MoCo employees we are asking to test nightly.

Comment 11

[Kohei Yoshino [:kohei]]

Chrome did it today. It's your turn. https://blog.chromium.org/2017/08/run-multiple-versions-of-chrome-side-by.html

Comment 12

[pvinis]

well actually chrome supported one profile for regular and beta release, and a separate one for canary, for a long long time now. that's the first step at least. I don't care so much about regular and beta separation. but nightly separation should be there. it would make testing it and using it daily do much easier.

Comment 13

[Michał Gołębiowski-Owczarek [:mgol]]

Firefox Developer Edition already uses a separate profile by default with a checkbox to stop doing that. Is there a reason a similar solution can't be employed on Nightly?

This issue is the reason why I'm not even suggesting installing Firefox Nightly to people that otherwise regularly test & develop sites using Chrome Canary.

Comment 14

[Andy McKay]

I would like to echo Jeff's comment 4 and request a bump in priority, we've seen this cause a problem more than once as users switch up and down the channels and hit schema changes.

Comment 15

[Kris Maglione [:kmag]]

This is now affecting users who are testing new version of uBlock Origin (bug 1371255 comment c21), which is causing blowback over their migration to a WebExtension (https://github.com/gorhill/uBlock/releases/tag/1.14.0)

Comment 16

[Zibi Braniecki [:zbraniecki][:gandalf]]

We have anecdotal evidence [0] that lack of this separation causes problems for users who use Firefox stable, would like to try Nightly, but are afraid that this is irreversible (due to lack of downgrade support from Nightly to Stable).

I'd also like to ask for a bump in priority as it hinders our ability to attract more people to test Nightly.

[0] https://www.reddit.com/r/javascript/comments/6xj93p/all_hands_on_deck_how_you_can_use_your_skills_to/dmgs02j/

Comment 17

[YF (Yang)]

Just a reminder, I don't like it like the Firefox Developer Edition, it is trouble for reset the selected item to default profile name always in profile manager. Adding a switch in profiles.ini will be pleasing.

Comment 18

[Pierre Chazal]

Default dedicated profiles per channel have always existed in Opera and for some days in Chrome (it existed before only for Canary)

http://www.chromium.org/getting-involved/dev-channel

It is done in Dev Edition and it would be useful in Nightly (instead of creating line commands, etc)

Comment 19

[Pierre Chazal]

https://blog.chromium.org/

Find 'run multiple versions', August 21th

Comment 20

[Zibi Braniecki [:zbraniecki][:gandalf]]

If this cannot be triaged higher, can we at least add a warning if the user is trying to downgrade to save users from datalosses?

Comment 22

[Romain Testard [:RT]]

We're now looking at implementation for this, currently targeting Firefox 59.
I'm assigning to Panos so he can recommend the right engineer.

Comment 23

[Dave Townsend [:mossop]]

I'm taking this.

Comment 25

[Adrian Florinescu [:aflorinescu]]

Updating the status flags to reflect that this feature is planned for FF60.

Comment 27

[Julien Cristau [:jcristau]]

AIUI this won't make 60.

Comment 28

[John Karahalis [:openjck]]

Any chance the Firefox team can prioritize this? I know comments like these are annoying, but I'd rather be annoying now as opposed to being annoying when there's another big push for people to use Nightly.

Comment 29

[Andrew Sutherland [:asuth] (he/him)]

Relatedly, we are planning to land an overhaul of LocalStorage in 61, and it will not be downgrade-friendly.  If it's possible to get a likelihood estimation for whether this will land in 61 or not, that would help plan mitigations and understand the risk and scope of the fallout from that[1].  Thanks!

1: The good news is that we've seen the worst-case breakage profile before with the release of Firefox 55 when LocalStorage was bumped to v2 along with QuotaManager v2 and IndexedDB v26, and we aim to do better than that, but due to the loss of the TDC, we're still behind on mitigations.  See https://public.etherpad-mozilla.org/p/quota-manager-schema-change-log for other schema change context.

Comment 30

[Dave Townsend [:mossop]]

(In reply to Andrew Sutherland [:asuth] from comment #29)
> Relatedly, we are planning to land an overhaul of LocalStorage in 61, and it
> will not be downgrade-friendly.  If it's possible to get a likelihood
> estimation for whether this will land in 61 or not, that would help plan
> mitigations and understand the risk and scope of the fallout from that[1]. 
> Thanks!

We don't currently have a safe enough implementation plan for this feature. As it stands this feature has been moved to the backlog.

Comment 31

[:Atoll]

Would it be valuable for us to implement a one-time “You’re opening a non-Nightly profile in Nightly, this may break non-Nightly channels” warning when a Release profile is first exposed to Nightly, prior to conversions and such?

Comment 32

[Dave Townsend [:mossop]]

(In reply to Richard Soderberg  [:atoll] [:�] from comment #31)
> Would it be valuable for us to implement a one-time “You’re opening a
> non-Nightly profile in Nightly, this may break non-Nightly channels” warning
> when a Release profile is first exposed to Nightly, prior to conversions and
> such?

That doesn't really solve the problem of version downgrades.

Comment 33

[Masatoshi Kimura [:emk]]

(In reply to Dave Townsend [:mossop] from comment #32)
> (In reply to Richard Soderberg  [:atoll] [:�] from comment #31)
> > Would it be valuable for us to implement a one-time “You’re opening a
> > non-Nightly profile in Nightly, this may break non-Nightly channels” warning
> > when a Release profile is first exposed to Nightly, prior to conversions and
> > such?
> 
> That doesn't really solve the problem of version downgrades.

Do we solve the problem of version downgrades at all?  I thought we didn't support downgrading profiles.

Comment 34

[Kohei Yoshino [:kohei]]

Firefox 55+ no longer supports downgrading as clearly stated in the release notes:
https://www.mozilla.org/en-US/firefox/55.0/releasenotes/

Comment 35

[Dave Townsend [:mossop]]

(In reply to Masatoshi Kimura [:emk] from comment #33)
> (In reply to Dave Townsend [:mossop] from comment #32)
> > (In reply to Richard Soderberg  [:atoll] [:�] from comment #31)
> > > Would it be valuable for us to implement a one-time “You’re opening a
> > > non-Nightly profile in Nightly, this may break non-Nightly channels” warning
> > > when a Release profile is first exposed to Nightly, prior to conversions and
> > > such?
> > 
> > That doesn't really solve the problem of version downgrades.
> 
> Do we solve the problem of version downgrades at all?  I thought we didn't
> support downgrading profiles.

We don't "support it" as in we know that currently things break when you downgrade (different things for different versions) and we don't invest any engineering effort to either avoid that or notify users that things might be broken or they might lose data by losing older versions.

Comment 36

[Masatoshi Kimura [:emk]]

(In reply to Dave Townsend [:mossop] from comment #35)
> (In reply to Masatoshi Kimura [:emk] from comment #33)
> > (In reply to Dave Townsend [:mossop] from comment #32)
> > > (In reply to Richard Soderberg  [:atoll] [:�] from comment #31)
> > > > Would it be valuable for us to implement a one-time “You’re opening a
> > > > non-Nightly profile in Nightly, this may break non-Nightly channels” warning
> > > > when a Release profile is first exposed to Nightly, prior to conversions and
> > > > such?
> > > 
> > > That doesn't really solve the problem of version downgrades.
> > 
> > Do we solve the problem of version downgrades at all?  I thought we didn't
> > support downgrading profiles.
> 
> We don't "support it" as in we know that currently things break when you
> downgrade (different things for different versions) and we don't invest any
> engineering effort to either avoid that or notify users that things might be
> broken or they might lose data by losing older versions.

So, why "That doesn't really solve the problem of version downgrades." matters?  We don't care about it anyway.
But we should at least prevent profiles from breaking silently.

Comment 37

[Dave Townsend [:mossop]]

(In reply to Masatoshi Kimura [:emk] from comment #36)
> (In reply to Dave Townsend [:mossop] from comment #35)
> > (In reply to Masatoshi Kimura [:emk] from comment #33)
> > > (In reply to Dave Townsend [:mossop] from comment #32)
> > > > (In reply to Richard Soderberg  [:atoll] [:�] from comment #31)
> > > > > Would it be valuable for us to implement a one-time “You’re opening a
> > > > > non-Nightly profile in Nightly, this may break non-Nightly channels” warning
> > > > > when a Release profile is first exposed to Nightly, prior to conversions and
> > > > > such?
> > > > 
> > > > That doesn't really solve the problem of version downgrades.
> > > 
> > > Do we solve the problem of version downgrades at all?  I thought we didn't
> > > support downgrading profiles.
> > 
> > We don't "support it" as in we know that currently things break when you
> > downgrade (different things for different versions) and we don't invest any
> > engineering effort to either avoid that or notify users that things might be
> > broken or they might lose data by losing older versions.
> 
> So, why "That doesn't really solve the problem of version downgrades."
> matters?  We don't care about it anyway.
> But we should at least prevent profiles from breaking silently.

The problem is that switching profile often causes a version downgrade which is what breaks the profile. This bug helps with that but doesn't completely solve it.

But I think we're diverging from this bug at this point. By all means file new bugs or start newsgroup threads on alternate solutions.

Comment 38

[Romain Testard [:RT]]

Andrew, what will be the impact on user experience for users downgrading after the overhaul of LocalStorage in 61?

Adrian thought before about an opt-in solution as a mitigation for this issue, the reach would be smaller since it would not be automated though users would have a way to get back to a working configuration:
- when a user switches from an older Firefox version to a newer one on different channels expose a UI informing of the potential risks to switch back with a a simple way to let them clone their profile and set the clone as default on the current channel so they end-up using 2 different profiles

I'm unsure who big of a task this is though. We may even want to consider creating a fresh new profile if cloning it too complex of a task. Anyway I created bug 1449868 to discuss this and we can set the priority based on user impact of the overhaul of LocalStorage in 61 and implementation complexity.

Comment 39

[Andrew Sutherland [:asuth] (he/him)]

I've commented on bug 1449868 for the alternative strategy.

I am still reviewing and investigating the LocalStorage situation, but I think the most likely answer is that on downgrade across the schema cliff we'll wipe out the contents of the user's LocalStorage, IndexedDB, Cache API, asm.js, and installed ServiceWorkers.  This will impact WebExtension use of these storages, although their "storage.local" mechanism will not be impacted until bug 1406181 lands.  However, the user's history, bookmarks, cookies, saved passwords, etc. will all be intact, and so a user shouldn't need to re-login to sites.

Note that de may have to delay landing LocalStorage to 62 so that we can land the data wiping logic in 61 and make sure there's telemetry attached.

Comment 40

[Jeff Griffiths (:canuckistani) (:⚡︎)]

(In reply to Andrew Sutherland [:asuth] from comment #39)
...
> I am still reviewing and investigating the LocalStorage situation, but I
> think the most likely answer is that on downgrade across the schema cliff
> we'll wipe out the contents of the user's LocalStorage, IndexedDB, Cache
> API, asm.js, and installed ServiceWorkers.  

I think this is acceptable, but happy to discuss if there are strong feelings against this. I *do* think in the downgrade case it is reasonable to warn the user, and direct them to a SUMO article.

Comment 41

[Dave Townsend [:mossop]]

We're going with bug 1474285 instead here.