info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Switching to per-channel profiles
175 views
Skip to first unread message
Dave Townsend
Jun 23, 2017, 6:44:06 PM6/23/17
to Firefox Dev, dev-pl...@lists.mozilla.org
TL;DR: We should make each Firefox channel use its own profile data
allowing you to run multiple channels at the same time.
Running multiple channels of Firefox is currently harder than it needs to
be. You can't start more than one channel at a time and either you use the
same profile data for each channel running the risk of hitting bugs with
downgrades or you have to create custom shortcuts to use different profiles
for each channel. The exception to this is the developer edition which uses
its own profile data by default. This turned out to be what most developers
wanted and matches Chrome's behaviour. So we should do the same thing for
the other channels.
The technical details of how to do this are a little challenging so here is
a proposal that hopes to limit the impact of the change:
* Release will continue to work as it does today. The default profile
listed in profiles.ini will be loaded and used as normal.
* When Nightly and Beta first start they will look for a profile to use:
** First choice will be determined by a new flag in profiles.ini for each
channel.
** Second choice will be a profile with a specific name which will be
different for each channel. We do this because if the user runs an older
build of Firefox it will blow away the new flags we use above.
** Finally if no profile has been found a new profile will be created with
the appropriate name.
* Throughout, if the command line includes --profile or -P to choose a
specific profile then we respect that.
The developer edition already does effectively the above just without the
custom flag which allows you to rename your profile (
https://bugzilla.mozilla.org/show_bug.cgi?id=1098986). As part of this we
would upgrade developer edition to support this too.
How we populate the new profile we create for Nightly and Beta channels is
an open question. We could simply clone the existing Release profile or use
Firefox Refresh to copy across the basic data. In either case we can notify
the user to let them know what has happened.
If users still want to share profiles between channels then they will have
that option going forwards by simply going to about:profiles and choosing a
different default profile for the channel they are running.
The main issue with this proposal is what happens if users downgrade
Nightly or Beta to a version before we make these changes. They will revert
back to the existing profile selection mechanism, effectively sharing
profiles with the release channel again. Upgrading again will take them
back to their new default profile unless they have renamed it away from the
custom name we choose in which case a new default will be created again.
Does anyone think we shouldn't do this or have comments on my proposal for
implementing it?
allowing you to run multiple channels at the same time.
Running multiple channels of Firefox is currently harder than it needs to
be. You can't start more than one channel at a time and either you use the
same profile data for each channel running the risk of hitting bugs with
downgrades or you have to create custom shortcuts to use different profiles
for each channel. The exception to this is the developer edition which uses
its own profile data by default. This turned out to be what most developers
wanted and matches Chrome's behaviour. So we should do the same thing for
the other channels.
The technical details of how to do this are a little challenging so here is
a proposal that hopes to limit the impact of the change:
* Release will continue to work as it does today. The default profile
listed in profiles.ini will be loaded and used as normal.
* When Nightly and Beta first start they will look for a profile to use:
** First choice will be determined by a new flag in profiles.ini for each
channel.
** Second choice will be a profile with a specific name which will be
different for each channel. We do this because if the user runs an older
build of Firefox it will blow away the new flags we use above.
** Finally if no profile has been found a new profile will be created with
the appropriate name.
* Throughout, if the command line includes --profile or -P to choose a
specific profile then we respect that.
The developer edition already does effectively the above just without the
custom flag which allows you to rename your profile (
https://bugzilla.mozilla.org/show_bug.cgi?id=1098986). As part of this we
would upgrade developer edition to support this too.
How we populate the new profile we create for Nightly and Beta channels is
an open question. We could simply clone the existing Release profile or use
Firefox Refresh to copy across the basic data. In either case we can notify
the user to let them know what has happened.
If users still want to share profiles between channels then they will have
that option going forwards by simply going to about:profiles and choosing a
different default profile for the channel they are running.
The main issue with this proposal is what happens if users downgrade
Nightly or Beta to a version before we make these changes. They will revert
back to the existing profile selection mechanism, effectively sharing
profiles with the release channel again. Upgrading again will take them
back to their new default profile unless they have renamed it away from the
custom name we choose in which case a new default will be created again.
Does anyone think we shouldn't do this or have comments on my proposal for
implementing it?
Mike Hommey
Jun 23, 2017, 7:11:57 PM6/23/17
to Dave Townsend, dev-pl...@lists.mozilla.org, Firefox Dev
profile, while, in practice, few of them are juggling with versions. How
about only switching to a new profile if the update channel is different
from the last time the existing profile was used?
Also, what about ESR?
Mike
Dave Townsend
Jun 23, 2017, 7:28:44 PM6/23/17
to Mike Hommey, dev-pl...@lists.mozilla.org, Firefox Dev
that at the moment. It would also mean that someone who exclusively uses
nightly but then much later after we implemented this installed release
would see release "steal" their profile. Maybe that's no different to it
happening right when we implement it.
Perhaps it would be worth, as a separate exercise, offering to clean up
profiles that have been unused for a long period of time.
> Also, what about ESR?
Good point. I think we would treat it like a release so just keep the
existing profile behaviour.
Dave Townsend
Jun 23, 2017, 7:42:14 PM6/23/17
to Aki Sasaki, dev-pl...@lists.mozilla.org, Firefox Dev
On Fri, Jun 23, 2017 at 4:37 PM, Aki Sasaki <asa...@mozilla.com> wrote:
> I'm a Nightly only user who periodically uses Release, and I'm not
> thrilled with the idea of my profile going away. Nightly users are probably
> better suited to dealing with this (using sync, etc) than the Beta
> population. Aiui, some Beta users aren't conscious Beta users, just people
> chosen to be in the Beta population when first installing Firefox; they may
> be less prepared to deal with their profile going away.
>
Which is why I really want us to consider creating the profile using some
or all of the existing default profile data. It adds an extra step to the
work but means that most users who only run with one profile will see
essentially no change to their workflow.
> Have we considered changing the "*Close Firefox* Only one copy..." alert
> to a profile switcher dialog, with a message like "Another copy of Firefox
> is using this profile. Use another profile?"
>
I need to look up what circumstances this dialog appears in. On Windows for
example trying to run Nightly when Beta is already open should just open a
new Beta window currently causing some surprise.
> I'm a Nightly only user who periodically uses Release, and I'm not
> thrilled with the idea of my profile going away. Nightly users are probably
> better suited to dealing with this (using sync, etc) than the Beta
> population. Aiui, some Beta users aren't conscious Beta users, just people
> chosen to be in the Beta population when first installing Firefox; they may
> be less prepared to deal with their profile going away.
>
Which is why I really want us to consider creating the profile using some
or all of the existing default profile data. It adds an extra step to the
work but means that most users who only run with one profile will see
essentially no change to their workflow.
> Have we considered changing the "*Close Firefox* Only one copy..." alert
> to a profile switcher dialog, with a message like "Another copy of Firefox
> is using this profile. Use another profile?"
>
I need to look up what circumstances this dialog appears in. On Windows for
example trying to run Nightly when Beta is already open should just open a
new Beta window currently causing some surprise.
Richard Newman
Jun 23, 2017, 7:45:45 PM6/23/17
to Dave Townsend, dev-platform, Firefox Dev
>
> How we populate the new profile we create for Nightly and Beta channels is
> an open question. We could simply clone the existing Release profile or use
> Firefox Refresh to copy across the basic data. In either case we can notify
> the user to let them know what has happened.
>
Use some caution with this: it's important that the resulting profile
> How we populate the new profile we create for Nightly and Beta channels is
> an open question. We could simply clone the existing Release profile or use
> Firefox Refresh to copy across the basic data. In either case we can notify
> the user to let them know what has happened.
>
doesn't share Sync or active FxA state — e.g., clientID, deviceID — with
the source profile. The Sync team can advise if this course of action is
chosen.
In general it's not safe to copy profiles in the presence of Sync.
Mike Hommey
Jun 23, 2017, 8:02:02 PM6/23/17
to Dave Townsend, dev-pl...@lists.mozilla.org, Firefox Dev, Aki Sasaki
On Fri, Jun 23, 2017 at 04:42:05PM -0700, Dave Townsend wrote:
> On Fri, Jun 23, 2017 at 4:37 PM, Aki Sasaki <asa...@mozilla.com> wrote:
>
> > I'm a Nightly only user who periodically uses Release, and I'm not
> > thrilled with the idea of my profile going away. Nightly users are probably
> > better suited to dealing with this (using sync, etc) than the Beta
> > population. Aiui, some Beta users aren't conscious Beta users, just people
> > chosen to be in the Beta population when first installing Firefox; they may
> > be less prepared to deal with their profile going away.
> >
>
> Which is why I really want us to consider creating the profile using some
> or all of the existing default profile data. It adds an extra step to the
> work but means that most users who only run with one profile will see
> essentially no change to their workflow.
Except they'd have a stale unused profile taking disk space for nothing.
> On Fri, Jun 23, 2017 at 4:37 PM, Aki Sasaki <asa...@mozilla.com> wrote:
>
> > I'm a Nightly only user who periodically uses Release, and I'm not
> > thrilled with the idea of my profile going away. Nightly users are probably
> > better suited to dealing with this (using sync, etc) than the Beta
> > population. Aiui, some Beta users aren't conscious Beta users, just people
> > chosen to be in the Beta population when first installing Firefox; they may
> > be less prepared to deal with their profile going away.
> >
>
> Which is why I really want us to consider creating the profile using some
> or all of the existing default profile data. It adds an extra step to the
> work but means that most users who only run with one profile will see
> essentially no change to their workflow.
> > Have we considered changing the "*Close Firefox* Only one copy..." alert
> > to a profile switcher dialog, with a message like "Another copy of Firefox
> > is using this profile. Use another profile?"
> >
>
> I need to look up what circumstances this dialog appears in. On Windows for
> example trying to run Nightly when Beta is already open should just open a
> new Beta window currently causing some surprise.
least for me on Linux. Not sure what actually happens on other
platforms.
Mike
Dave Townsend
Jun 23, 2017, 8:04:58 PM6/23/17
to Richard Newman, dev-platform, Firefox Dev
Richard Newman
Jun 23, 2017, 8:55:04 PM6/23/17
to Dave Townsend, dev-platform, Firefox Dev
What happens when users do that? Because they do.
A variety of kinda-horrible things will happen.
The two copied profiles will compete for the Sync client record. That means sent tabs will appear on one or the other, the Tabs from Other Devices list will flip-flop between each of the two devices, the count of devices will be wrong for scheduling purposes, and the two devices will unpredictably handle bookmark repair requests, leading to distributed inconsistency.
If the two profiles are used on different versions, the browser metadata in the client record will flip between the two, too.
Firefoxen that track who-did-what (e.g., on iOS we record whether a visit occurred locally or remotely) will both think they did the thing for all historical data.
>From an FxA perspective I'm less sure: for a while (perhaps a long while) I expect they'll pretend to be the same device wrt FxA. Only one will show up in your devices list.
We used to have the same problems with FHR, and perhaps telemetry, too.
Richard Newman
Jun 23, 2017, 9:15:16 PM6/23/17
to Dave Townsend, dev-platform, Firefox Dev
I should add that there are ways to detect and work around these situations, of varying levels of difficulty and specificity*; if there's sufficient motivation I can flesh out a bug.
* E.g., using server timestamps to detect whether another client is racing with us, and deciding that a profile copy must have occurred, at which point we can prompt, automatically rename ourselves, try to figure out which device was the original, etc.; and/or trying to use OS or device information to fingerprint and detect cross-machine profile copies.
* E.g., using server timestamps to detect whether another client is racing with us, and deciding that a profile copy must have occurred, at which point we can prompt, automatically rename ourselves, try to figure out which device was the original, etc.; and/or trying to use OS or device information to fingerprint and detect cross-machine profile copies.
Andrew McKay
Jun 23, 2017, 11:26:37 PM6/23/17
to Dave Townsend, dev-platform, Firefox Dev
+1
I think it will be great benefit if someone could run Nightly for
first time, whilst Firefox is running and not get the dreaded "Profile
in Use" dialog. We should do whatever we can to minimize the
appearance of that dialog, while still allowing -p to be passed in the
command line.
> (https://bugzilla.mozilla.org/show_bug.cgi?id=1098986). As part of this we
> firefox-dev mailing list
> firef...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>
I think it will be great benefit if someone could run Nightly for
first time, whilst Firefox is running and not get the dreaded "Profile
in Use" dialog. We should do whatever we can to minimize the
appearance of that dialog, while still allowing -p to be passed in the
command line.
> would upgrade developer edition to support this too.
>
>
> How we populate the new profile we create for Nightly and Beta channels is
> an open question. We could simply clone the existing Release profile or use
> Firefox Refresh to copy across the basic data. In either case we can notify
> the user to let them know what has happened.
>
> an open question. We could simply clone the existing Release profile or use
> Firefox Refresh to copy across the basic data. In either case we can notify
> the user to let them know what has happened.
>
> If users still want to share profiles between channels then they will have
> that option going forwards by simply going to about:profiles and choosing a
> different default profile for the channel they are running.
>
> The main issue with this proposal is what happens if users downgrade Nightly
> or Beta to a version before we make these changes. They will revert back to
> the existing profile selection mechanism, effectively sharing profiles with
> the release channel again. Upgrading again will take them back to their new
> default profile unless they have renamed it away from the custom name we
> choose in which case a new default will be created again.
>
> Does anyone think we shouldn't do this or have comments on my proposal for
> implementing it?
>
> _______________________________________________
> that option going forwards by simply going to about:profiles and choosing a
> different default profile for the channel they are running.
>
> The main issue with this proposal is what happens if users downgrade Nightly
> or Beta to a version before we make these changes. They will revert back to
> the existing profile selection mechanism, effectively sharing profiles with
> the release channel again. Upgrading again will take them back to their new
> default profile unless they have renamed it away from the custom name we
> choose in which case a new default will be created again.
>
> Does anyone think we shouldn't do this or have comments on my proposal for
> implementing it?
>
> firefox-dev mailing list
> firef...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>
Ben Hearsum
Jun 26, 2017, 9:03:08 AM6/26/17
to
selected profile without asking at startup" button (eg: if I select my
non-devedition profile with that checked, it still starts with the
DevEdition profile next time). If we're enabling similar logic across
all channels, we should probably fix this or get rid of the button
(since it will serve no function AFAICT).
- Ben
Gijs Kruitbosch
Jun 26, 2017, 9:07:15 AM6/26/17
to
Milan Sreckovic
Jun 27, 2017, 1:36:25 PM6/27/17
to dev-pl...@lists.mozilla.org
I don't know how common this workflow is for others, but I do find I
often need to use release/beta to "fix" experimental preferences when
things go wrong. For features that are behind a preference, in nightly,
if I set the preference, which leads to a start up crash, the easiest
way to reset it is to run the release on the same profile, reset the
preferences to the default, then run nightly again.
Fairly specialized case, I agree.
On a sync note, I'm not sure if I understood the conversation correctly,
but as long as I can run the same sync account on different machines,
with different versions of Firefox, I'm good.
On 23-Jun-17 18:43, Dave Townsend wrote:
> Does anyone think we shouldn't do this or have comments on my proposal for
> implementing it?
> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
--
- Milan (mi...@mozilla.com)
often need to use release/beta to "fix" experimental preferences when
things go wrong. For features that are behind a preference, in nightly,
if I set the preference, which leads to a start up crash, the easiest
way to reset it is to run the release on the same profile, reset the
preferences to the default, then run nightly again.
Fairly specialized case, I agree.
On a sync note, I'm not sure if I understood the conversation correctly,
but as long as I can run the same sync account on different machines,
with different versions of Firefox, I'm good.
On 23-Jun-17 18:43, Dave Townsend wrote:
> Does anyone think we shouldn't do this or have comments on my proposal for
> implementing it?
> _______________________________________________
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
--
- Milan (mi...@mozilla.com)
Ehsan Akhgari
Jun 27, 2017, 1:48:47 PM6/27/17
to Milan Sreckovic, dev-pl...@lists.mozilla.org
On 06/27/2017 01:36 PM, Milan Sreckovic wrote:
> I don't know how common this workflow is for others, but I do find I
> often need to use release/beta to "fix" experimental preferences when
> things go wrong. For features that are behind a preference, in
> nightly, if I set the preference, which leads to a start up crash, the
> easiest way to reset it is to run the release on the same profile,
> reset the preferences to the default, then run nightly again.
>
> Fairly specialized case, I agree.
FWIW this case is destructive to your profile data currently (in often
> I don't know how common this workflow is for others, but I do find I
> often need to use release/beta to "fix" experimental preferences when
> things go wrong. For features that are behind a preference, in
> nightly, if I set the preference, which leads to a start up crash, the
> easiest way to reset it is to run the release on the same profile,
> reset the preferences to the default, then run nightly again.
>
> Fairly specialized case, I agree.
invisible ways), see bug 1246615, which I believe is one of the driving
forces behind this change.
Aki Sasaki
Jun 27, 2017, 2:48:10 PM6/27/17
to Dave Townsend, Mike Hommey, dev-pl...@lists.mozilla.org, Firefox Dev
I'm a Nightly only user who periodically uses Release, and I'm not thrilled
with the idea of my profile going away. Nightly users are probably better
suited to dealing with this (using sync, etc) than the Beta population.
Aiui, some Beta users aren't conscious Beta users, just people chosen to be
in the Beta population when first installing Firefox; they may be less
prepared to deal with their profile going away.
with the idea of my profile going away. Nightly users are probably better
suited to dealing with this (using sync, etc) than the Beta population.
Aiui, some Beta users aren't conscious Beta users, just people chosen to be
in the Beta population when first installing Firefox; they may be less
prepared to deal with their profile going away.
Have we considered changing the "*Close Firefox* Only one copy..." alert to
a profile switcher dialog, with a message like "Another copy of Firefox is
using this profile. Use another profile?"
On Fri, Jun 23, 2017 at 4:28 PM, Dave Townsend <dtow...@mozilla.com>
a profile switcher dialog, with a message like "Another copy of Firefox is
using this profile. Use another profile?"
wrote:
> > > How we populate the new profile we create for Nightly and Beta channels
> > is
> > > an open question. We could simply clone the existing Release profile or
> > use
> > > Firefox Refresh to copy across the basic data. In either case we can
> > notify
> > > the user to let them know what has happened.
> > >
> > > If users still want to share profiles between channels then they will
> > have
> > > that option going forwards by simply going to about:profiles and
> > choosing a
> > > different default profile for the channel they are running.
> > >
> > > The main issue with this proposal is what happens if users downgrade
> > > Nightly or Beta to a version before we make these changes. They will
> > revert
> > > back to the existing profile selection mechanism, effectively sharing
> > > profiles with the release channel again. Upgrading again will take them
> > > back to their new default profile unless they have renamed it away from
> > the
> > > custom name we choose in which case a new default will be created
> again.
> > >
> > is
> > > an open question. We could simply clone the existing Release profile or
> > use
> > > Firefox Refresh to copy across the basic data. In either case we can
> > notify
> > > the user to let them know what has happened.
> > >
> > > If users still want to share profiles between channels then they will
> > have
> > > that option going forwards by simply going to about:profiles and
> > choosing a
> > > different default profile for the channel they are running.
> > >
> > > The main issue with this proposal is what happens if users downgrade
> > > Nightly or Beta to a version before we make these changes. They will
> > revert
> > > back to the existing profile selection mechanism, effectively sharing
> > > profiles with the release channel again. Upgrading again will take them
> > > back to their new default profile unless they have renamed it away from
> > the
> > > custom name we choose in which case a new default will be created
> again.
> > >
> > > Does anyone think we shouldn't do this or have comments on my proposal
> > for
> > > implementing it?
> >
> > for
> > > implementing it?
> >
> > It sounds like this will make every user of non-Release create a new
> > profile, while, in practice, few of them are juggling with versions. How
> > about only switching to a new profile if the update channel is different
> > from the last time the existing profile was used?
> >
>
> Yeah that would be a good idea but I don't think we have any way to detect
> that at the moment. It would also mean that someone who exclusively uses
> nightly but then much later after we implemented this installed release
> would see release "steal" their profile. Maybe that's no different to it
> happening right when we implement it.
>
> Perhaps it would be worth, as a separate exercise, offering to clean up
> profiles that have been unused for a long period of time.
>
>
> > Also, what about ESR?
>
>
> Good point. I think we would treat it like a release so just keep the
> existing profile behaviour.
> > profile, while, in practice, few of them are juggling with versions. How
> > about only switching to a new profile if the update channel is different
> > from the last time the existing profile was used?
> >
>
> Yeah that would be a good idea but I don't think we have any way to detect
> that at the moment. It would also mean that someone who exclusively uses
> nightly but then much later after we implemented this installed release
> would see release "steal" their profile. Maybe that's no different to it
> happening right when we implement it.
>
> Perhaps it would be worth, as a separate exercise, offering to clean up
> profiles that have been unused for a long period of time.
>
>
> > Also, what about ESR?
>
>
> Good point. I think we would treat it like a release so just keep the
> existing profile behaviour.
Randell Jesup
Jul 10, 2017, 2:25:35 PM7/10/17
to
>What happens when users do that? Because they do.
>
>A variety of kinda-horrible things will happen.
>
>The two copied profiles will compete for the Sync client record. That means
>sent tabs will appear on one or the other, the Tabs from Other Devices list
>will flip-flop between each of the two devices, the count of devices will
>be wrong for scheduling purposes, and the two devices will unpredictably
>handle bookmark repair requests, leading to distributed inconsistency.
Ouch. Glad when I copied profiles I didn't (and still don't) use Sync;
>
>A variety of kinda-horrible things will happen.
>
>The two copied profiles will compete for the Sync client record. That means
>sent tabs will appear on one or the other, the Tabs from Other Devices list
>will flip-flop between each of the two devices, the count of devices will
>be wrong for scheduling purposes, and the two devices will unpredictably
>handle bookmark repair requests, leading to distributed inconsistency.
having this happen would be ... surprising - and painful, sounds like.
I wonder if it's possible to flag moved (or copied) profiles, and force
them to go through some sort of re-sync (effectively become a "new"
client for the account, even if it was only moved to a new disk location).
That *should* in theory avoid the consistency problem, and only annoy
users without reason in the odd case where the moved their profile(s).
--
Randell Jesup, Mozilla Corp
remove "news" for personal email
Kris Maglione
Jul 10, 2017, 2:36:35 PM7/10/17
to Ehsan Akhgari, Milan Sreckovic, dev-pl...@lists.mozilla.org
On Tue, Jun 27, 2017 at 01:48:33PM -0400, Ehsan Akhgari wrote:
>On 06/27/2017 01:36 PM, Milan Sreckovic wrote:
>>I don't know how common this workflow is for others, but I do find I
>>often need to use release/beta to "fix" experimental preferences
>>when things go wrong. For features that are behind a preference, in
>>nightly, if I set the preference, which leads to a start up crash,
>>the easiest way to reset it is to run the release on the same
>>profile, reset the preferences to the default, then run nightly
>>again.
>>
>>Fairly specialized case, I agree.
>
>FWIW this case is destructive to your profile data currently (in often
>invisible ways), see bug 1246615, which I believe is one of the
>driving forces behind this change.
Also, we should already handle this by starting up in safe mode
>On 06/27/2017 01:36 PM, Milan Sreckovic wrote:
>>I don't know how common this workflow is for others, but I do find I
>>often need to use release/beta to "fix" experimental preferences
>>when things go wrong. For features that are behind a preference, in
>>nightly, if I set the preference, which leads to a start up crash,
>>the easiest way to reset it is to run the release on the same
>>profile, reset the preferences to the default, then run nightly
>>again.
>>
>>Fairly specialized case, I agree.
>
>FWIW this case is destructive to your profile data currently (in often
>invisible ways), see bug 1246615, which I believe is one of the
>driving forces behind this change.
after 3 startup crashes, at which point you should be able to
flip that pref back without downgrading.
If starting up in safe mode still fails in that case, please
file a bug. We should be able to handle this without resorting
to arcane workarounds.
0 new messages