Status

()

enhancement
RESOLVED WONTFIX
2 years ago
20 days ago

People

(Reporter: RT, Assigned: mossop)

Tracking

(Depends on 2 bugs, Blocks 2 bugs)

unspecified
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox57 wontfix, firefox58 wontfix, firefox59 wontfix, firefox60 wontfix)

Details

User Story

Per discussion on bug 1246615, it was identified that 0.48% switch Firefox channels. This is a supported use case and our goal is to make profiles backwards and forwards compatible although this is a hard goal to achieve and number of developers suffer from profile corruption issues when using profiles from the future.
Using per channel profiles was agreed as the most suitable solution for the problem and this bug will first track scoping for this and then implementation.
 
User story: As a software developer, I want to switch Firefox channels without suffering profile corruption issues so my life gets simpler.
 
Acceptance criteria:
Nightly, Beta and release channels have dedicated default profiles
Users can use a Firefox channel with a profile from any other channel (using nightly with their release profile being the lead use case) from the command line
 
Next steps:
Get these requirements reviewed/augmented (Benjamin mentioned we still need to specify a bunch of details, such as what try/self builds get by default and how migration will work)
Comment hidden (empty)
(Reporter)

Updated

2 years ago
User Story: (updated)
(Reporter)

Updated

2 years ago
Blocks: 1246615

Comment 1

2 years ago
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.
Flags: needinfo?(rtestard)
(Reporter)

Comment 2

2 years ago
(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.
Flags: needinfo?(rtestard)
(Assignee)

Comment 3

2 years ago
Please see https://groups.google.com/forum/#!topic/mozilla.dev.platform/-caAmk_ijnY where I proposed a way to achieve this.
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.
(Assignee)

Updated

2 years ago
Duplicate of this bug: 1255740

Comment 12

2 years ago
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.
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

2 years ago
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.
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)
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

2 years ago
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

2 years ago
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

2 years ago
https://blog.chromium.org/

Find 'run multiple versions', August 21th
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?
Severity: normal → enhancement

Updated

2 years ago
Duplicate of this bug: 1396806
(Reporter)

Comment 22

2 years ago
We're now looking at implementation for this, currently targeting Firefox 59.
I'm assigning to Panos so he can recommend the right engineer.
Assignee: nobody → past
(Assignee)

Comment 23

2 years ago
I'm taking this.
Assignee: past → dtownsend
See Also: → 1415385
Duplicate of this bug: 1421045
Updating the status flags to reflect that this feature is planned for FF60.
Depends on: 1436607

Updated

a year ago
Duplicate of this bug: 1439214
AIUI this won't make 60.
Comment hidden (advocacy)
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.
Flags: needinfo?(dtownsend)
(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.
Flags: needinfo?(dtownsend)

Comment 31

a year ago
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?
(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.
(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.
Firefox 55+ no longer supports downgrading as clearly stated in the release notes:
https://www.mozilla.org/en-US/firefox/55.0/releasenotes/
(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.
(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.
(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.
(Reporter)

Comment 38

a year ago
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.
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.
(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.
(Assignee)

Updated

10 months ago
See Also: → 1474285
(Assignee)

Comment 41

7 months ago
We're going with bug 1474285 instead here.
Status: NEW → RESOLVED
Last Resolved: 7 months ago
Resolution: --- → WONTFIX
No longer depends on: 1435710
You need to log in before you can comment on or make changes to this bug.