Closed Bug 895030 Opened 11 years ago Closed 7 years ago

Make Nightly use a different directory for profiles

Categories

(Firefox :: General, defect)

Product:
Firefox
Component:
General
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1373244

People

(Reporter: anton, Unassigned)

References

(Blocks 1 open bug,
URL
)

Details

Attachments

(1 file)

Screen Shot 2014-11-11 at 01.28.05.png
29.01 KB, image/png
Details 
Making Nightly use a different directory for profiles will allow web developers to run Nightly alongside their normal copy of Firefox without too much trouble. This will probably increase our Nightly adoption rate just like it did with Chrome Canary. 

Today all profiles are stored in the Firefox directory (e.g. Application Support/Firefox) and my proposal is to change that to FirefoxNightly.

If implemented this will be extremely helpful for the Developer Tools team (and I'm sure other teams working on desktop Firefox) to gather early feedback from web and Firefox OS developers.

Related ML thread: https://mail.mozilla.org/pipermail/firefox-dev/2013-July/000560.html
Include Aurora as well while we're at it, or do you want to keep that separate?
Aurora should offer a separate profile as well.
This kind of change could be highly disruptive to the volume and quality of feedback we get from Nightly users. Do we know that this won't decimate the testing volume as people find themselves with Nightly as a secondary instead if primary profile? Sync is not an answer (yet.)
See also: bug 287896, bug 443078. I have generally been opposed to this idea in the past, but I'm open to revisiting this since I appreciate the benefits.

Jared brought up migrating existing users on firefox-dev, which could be complicated. I suppose we may be able to punt on it by trying to somehow have this affect only new users?
OS: Mac OS X → All
Hardware: x86 → All
(In reply to Asa Dotzler [:asa] from comment #3)
> This kind of change could be highly disruptive to the volume and quality of
> feedback we get from Nightly users. Do we know that this won't decimate the
> testing volume as people find themselves with Nightly as a secondary instead
> if primary profile? Sync is not an answer (yet.)

Surely a large proportion of nightly users are advanced users who will have set up a separate profile manually to avoid the risk damaging there release profile. With this in mind would it not mean there would be more users willing to use nightly as it would automatically separate their profile meaning less effort to set up?
(In reply to uy2251+bugzilla from comment #7)
> (In reply to Asa Dotzler [:asa] from comment #3)
> > Do we know that this won't decimate the
> > testing volume as people find themselves with Nightly as a secondary instead
> > if primary profile? Sync is not an answer (yet.)
> 
> Surely a large proportion of nightly users are advanced users who will have
> set up a separate profile manually to avoid the risk damaging there release
> profile.

I asked what we know and you responded with your belief. We need data here.
(In reply to uy2251+bugzilla from comment #7)
> Surely a large proportion of nightly users are advanced users who will have
> set up a separate profile manually to avoid the risk damaging there release
> profile.

I can only speak for myself, but I use my "release" profile on Aurora and Nightly quite regularly.  If I was forced to use different profiles in each build, I'd simply use each build far less.

I think the risk that this might actually *lose* us users rather than gain new ones is real - but I've no feeling for how likely either outcome is.
(In reply to Mark Hammond (:markh) from comment #9)
> (In reply to uy2251+bugzilla from comment #7)
> > Surely a large proportion of nightly users are advanced users who will have
> > set up a separate profile manually to avoid the risk damaging there release
> > profile.
> 
> I can only speak for myself, but I use my "release" profile on Aurora and
> Nightly quite regularly.  If I was forced to use different profiles in each
> build, I'd simply use each build far less.
> 
> I think the risk that this might actually *lose* us users rather than gain
> new ones is real - but I've no feeling for how likely either outcome is.

This would not be a problem if we use the last used profile by default, and then if there is no last used profile (new Nightly user) we create a new profile specific to Nightly.
(In reply to Nick Fitzgerald [:fitzgen] from comment #10)
> This would not be a problem if we use the last used profile by default, and
> then if there is no last used profile (new Nightly user) we create a new
> profile specific to Nightly.

If you mean that the Nightly and the Release installs each keep track of their own last used profile separately then I fully support this.

I've messed up my "main" profile a number of times when it was inadvertently used by the nightly because I forgot to run it with -p. (and requested this behaviour in bug 769261)
> If you mean that the Nightly and the Release installs each keep track of their own last > used profile separately then I fully support this.

I was thinking the same thing, it seems like it would make everyone happy. I think having a default profile (last used profile) per installation path makes the most sense. 

> then if there is no last used profile (new Nightly user) we create a new 
> profile specific to Nightly

I don't know about this part, I prefer to just simply make it per installation path, and have a global last used profile for new installation paths.
by installation path I mean current binary path to cover zip and locally built builds.
It seems to me that Nightly on Android has its own profile. E.g., I have different add-ons in Nightly and Release. Is the percentage of users running Nightly different on Android and PC/Mac? That number might provide the data you are looking for.

If the profile management and use was greatly simplified this RFE might become a non-issue. At present it is so baroque as to be nearly unusable.

For example I set up 2 profiles, a "secure" (just my name for it)  one for on-line banking etc. and a general one. I also created a wrapper to launch FF with a -p option for the "secure" one. I use the regular FF icon to launch the general one. I have to constantly remember to launch the general one first otherwise, if the "secure" profile is running and I, for example, click a link in an e-mail message the resulting tab opens up in the "secure" browser. Just one of many traps for the unwary in the current set up.
My feelings are mixed on Nightly having its' own Profile. I have my own way of keeping Profiles separate, and launching "each version" with the correct Profile. As Jay mentioned, a nightly Profile is a nightly Profile - and never should it be used on Aurora, Beta, or Release even accidentally. The way I do it, those Profiles don't even appear in the profiles.ini file, they are not "Relative" to the default Profiles folderset.

Why limit this to just Nightly? Why not include Aurora, too? And then maybe Beta? Why not encourage Nightly users to use the Profile Manager XUL Runner application?

And with Bsmedberg's "threats" for the last 6 or 7 years that Profiles are (eventually) going to be removed from Firefox, why isn't that implemented instead?

As far as I am concerned, the best change (if any change is done) would be to "package" the Profile with the Program Files (similar to Portable Firefox) in such a manner as to allow the Profile Manager XUL Runner application to be used and to continue to allow "non-relative" Profiles to be launched by command line / a desktop shortcut & .mozilla/firefox-s/A/UX/N. And then do it across the board - Nightly, Aurora, Beta, and Release included!

As far as I am concerned, the reasoning behind that Bug report is flawed, by wanting to create a new way of doing things solely for the benefit of increasing the number of Nightly users to help the Firefox Developer Tools team. The Profile related module owners need to expand this concept far beyond the desires of the Firefox Developer Tools team and take into consideration all of the Firefox community before making any changes in that direction.
I'd really like to see non-release builds (i. e. Nightly, Aurora, but not Beta and Release, for various reasons) use their own Profile / data directory, too. 

As for migrating existing Nightly / Aurora users, I'm sure you can use the migration or reset assistant to move these users to a new profile. 

If you want to keep your profiles synced with Release profiles, you may want to use Firefox sync (with syncing preferences disabled).
I am in general opposed to the basic proposal here, although I understand both sides of the situation. At least I want these situations to work flawlessly before we try anything:

A:

* A user is using release and reports a bug having to do with some kind of profile data
* We believe we've fixed it and the fix is available in Nightly/Aurora/whatever
* We ask them to download the build with the fix and run it with their existing profile to check

B:

* A user is using a release build. They want to help Mozilla and we ask them to use Beta instead as their primary browser.
* It should be easy or the default to use beta with their existing profile.

I understand that there are cases, especially for web developers and people who cross branches all the time, where having a profile per channel branding makes more sense, but I *suspect* that this is the minority case and it will have serious side effects for the scenarios I listed.

Also I firmly oppose making it "per installation path" as in comment 12. There are too many ways for that to break or cause confusion in general, unless we specifically branded it as "portable Nightly" and the profile was inside the installation (and was deleted when the install was removed).
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #17)
> Also I firmly oppose making it "per installation path" as in comment 12.
> There are too many ways for that to break or cause confusion in general,
> unless we specifically branded it as "portable Nightly" and the profile was
> inside the installation (and was deleted when the install was removed).

I'm not sure if the "it" you're referring to is the same as what I was referring to. I think it's a bad idea to have a new profile per installation path created. 

I think it's a good idea to have a default profile (last used profile) per installation path.  This is a pretty easy fix and makes things more flexible. 

That means that no one would see any difference for existing users. I see no benefit in making all installation paths change to the last used profile as we have it now.  

If you want a different profile on Nightly, then you run Nightly with -ProfileManager once, create a profile, and set it, then all future launches from that installation path will use that new profile. 

By the way we could also make profile manager more accessible via platform integration tricks like on Windows we can add it to the jump list for Nightly and Aurora if we wanted to in a different bug.
(In reply to Brian R. Bondy [:bbondy] from comment #18)
> I think it's a good idea to have a default profile (last used profile) per
> installation path.  […] I see no
> benefit in making all installation paths change to the last used profile as
> we have it now.  

Yes, please! This will help *a lot*! 

Concerning a "Portable" version, how hard would it be for Moz to provide an official portable Nightly for all platforms that, apart from profile handling, acts and updates like the normal version? That way, devs can choose on download which version to use.
(In reply to Asa Dotzler [:asa] from comment #8)
> I asked what we know and you responded with your belief. We need data here.

Totally agree. Products like multifirefox ( http://davemartorana.com/multifirefox/ ) indicate a fair amount of interest in this, to the point that I see this as a developer-focused feature.

We need to get more data about what developers want from us generally, eg qualitative interviews that then form the basis for larger surveys.

Asa: if we discretely consider this a developer-oriented feature ( Chrome positions their solution in this way wrt Canary ) does that make this less scary?

The use cases I see look like:

* as a web developer I need to run different versions of Firefox simultaneously for testing
* I would like to run a separate 'development' profile of Firefox nightly/aurora with specific add-ons & prefs.

Most of the comments here are focused on the first idea, but I also see some interest in the second idea with developers. By interest, I mean they are already using things like multifirefox to accomplish this.
Note that our channels are not solely or primarily a developer-facing feature. They are primarily a way of providing quality feedback on the product, with users who have progressively less tolerance for bugs and higher expectations about the stability of the product.

It is also important to provide developers with early previews of new technologies, but I explicitly do not want to harm our ecosystem of testers in pursuit of web developers.
What about making |firefox -ProfileManager| the default behavior for Nightly?
fuck no. Can you be more user-hostile than that, for people who use this as their default browser?
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #21)
> Note that our channels are not solely or primarily a developer-facing
> feature. They are primarily a way of providing quality feedback on the
> product, with users who have progressively less tolerance for bugs and
> higher expectations about the stability of the product.
> 
> It is also important to provide developers with early previews of new
> technologies, but I explicitly do not want to harm our ecosystem of testers
> in pursuit of web developers.

I totally agree. From my POV this particular capability is mostly coming from developers. We could consider providing something like this to developers in a way that they can enable without having it affect most users.
From my POV, this talk about waiting to help WebDevs (and also the discussion in https://wiki.mozilla.org/Features/Desktop/Ability_to_run_concurrent_channels) isn't particularly high-value for us.  We seem to be focusing on people who want to use Nightly for very quick drive-by tests of their own sites - which they should be doing already anyway for their own selfish reasons.

High-value for us is encouraging people to use Nightly/Aurora as "daily drivers" as much as possible.  For me, that means using my regular profile.

So IMO, the major bug being described here is that some of us think people are insane to use their regular profile with Aurora or Nightly.  My main profile is many many years old, so I think the risk of major profile damage is overstated - but if it's not, we should be doing whatever it takes so Firefox developers are willing to trust their profile between channels.
From the perspective of releases, doing this would make it very difficult for external users to easily test prerelease channels when identifying a regression window. Differing profiles may prevent reproduction of a bug.

A more subtle solution that really gets to the root of this request is required.
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #21)
> Note that our channels are not solely or primarily a developer-facing
> feature. They are primarily a way of providing quality feedback on the
> product, with users who have progressively less tolerance for bugs and
> higher expectations about the stability of the product.

This highest-value category of users also seems to be the easiest to accommodate. The highest value is from people who always use the nightly, or always use aurora, if I understand you correctly. Therefore, they won't be affected in any way at all simply because they do not run multiple versions of Firefox or use multiple profiles.

Hence this entire discussion is about the less valuable categories of feedback, e.g. mine, when I test (or don't test) a bug in a Nightly before reporting it. Can someone point out what the problem is with remembering the last used profile separately for each installation? I don't believe it's been explained clearly yet.

The only scenario that's currently trivial that will no longer be trivial is when someone wants to switch between two profiles on two browsers, and uses both profiles on both browsers. This seems a lot less likely than what many commenters here want, although I am guessing of course.
(In reply to Roman from comment #27)
> (In reply to Benjamin Smedberg  [:bsmedberg] from comment #21)
> > Note that our channels are not solely or primarily a developer-facing
> > feature. They are primarily a way of providing quality feedback on the
> > product, with users who have progressively less tolerance for bugs and
> > higher expectations about the stability of the product.
> 
> This highest-value category of users also seems to be the easiest to
> accommodate. The highest value is from people who always use the nightly, or
> always use aurora, if I understand you correctly. Therefore, they won't be
> affected in any way at all simply because they do not run multiple versions
> of Firefox or use multiple profiles.

Not sure this is true; I think the goal here is to make it easier to run Nightly (or Aurora) as the daily driver, but make it easy to fall back to Aurora or Beta or release when something about Nightly is broken. But that doesn't work if Nightly upgraded my profile, so this bug is about offering people an easier way out (if Sync is good enough to resume usage in another profile).
(In reply to Alex Keybl [:akeybl] from comment #26)
> A more subtle solution that really gets to the root of this request is
> required.

(In reply to Roman from comment #27)
> Can someone point out what the problem is with remembering the
> last used profile separately for each installation? I don't believe it's
> been explained clearly yet.

Agreed, I haven't heard any negative feedback about it, I think it's the optimal solution, and has no negative impact on existing users.

(In reply to Roman from comment #27)
> The only scenario that's currently trivial that will no longer be trivial is when
> someone wants to switch between two profiles on two browsers, and uses both
> profiles on both browsers.

We could make the second launch of a firefox process (when not launched with any special command line parameters, and possibly when launched from a different path, and possibly if no profile has been set for that binary explicitly) bring up the profile manager directly, instead of doing a new tab in the existing process. This wouldn't affect when you click a link or open an HTML file which would open in the already opened browser.  If there is no open process already it would just open directly with the last used profile.

We can do things like make profile manager, or profiles themselves show up in jump lists for Windows, the firefox menu for all platforms, etc, making launching different profiles much easier with implied -p and -no-remote flags.  

These are all ways to make it easier to test both browsers at the same time.  
Either (or both) of the above ideas, when combined with the last used profile per launched binary, seems ideal to me.
I was simply addressing the bug as written, and introducing another variable (a release channel user's ability to help find a regression window). Last used profile may be a viable solution.
(In reply to Brian R. Bondy [:bbondy] from comment #29)
> (In reply to Roman from comment #27)
> > Can someone point out what the problem is with remembering the
> > last used profile separately for each installation? I don't believe it's
> > been explained clearly yet.
> 
> Agreed, I haven't heard any negative feedback about it, I think it's the
> optimal solution, and has no negative impact on existing users.

I think this is a fine idea, but doesn't solve the actual problem.  This will make it more convenient for people to manage multiple profiles.  However, by definition, those people have *already* started managing multiple profiles.  They have already started Firefox with -P, have already created a new profile and have developed some strategy for working with them.

This idea will make it more convenient for those people - indeed, most people CCd on this bug probably fall into that category.  IOW, this idea will be more convenient *for us*.  Awesome!  We should do it!

But it seems this bug is trying to solve the problem for a different set of people.  People who don't know to to work with multiple profiles.  People who aren't comfortable with arranging to start Firefox with a custom command-line, but who have read that using their regular profile is dangerous - so are kinda stuck.  ISTM your solution will not really help those people.

<record type="broken">IMO, the best thing we can do for those people is to say "just start Aurora/Nightly.  Forget profiles.  Just do it, you'll be fine!"</record>
> But it seems this bug is trying to solve the problem for a different set of people.  
> People who don't know to to work with multiple profiles.

Comment 29 actually does address these set of people as well with 2 options.

i)
The 2nd launch of a firefox process, when a different firefox process already exists, if from a different exe path, would launch profile manager, and introduce the user to profiles.  "Looks like you're already using your Firefox profile, would you like to create a new one?".  What we do today is just launch a window in the old process and close down.  

ii) 
Make profile manager, or profiles themselves more accessible via shell integration and Firefox menu option.
I guess I'm suggesting that the key audience we are trying to fix things for don't know about profiles and don't really want to know about them.  A subset of them might be willing to learn about them, but only because we say it's unsafe to trust their profile with these other channels.

To put it another way: people should not be forced to learn about and deal with profiles just so they can safely run Aurora and Nightly.  Some people may choose to learn about profiles because they want what multiple profiles can offer (and we should make it as easy as possible for them) - but it should be their choice and in their own time and unrelated to the choice about what channel to use.
Personally I think as long as we're friendly about it, we shouldn't hide from exposing profiles.

If the user has multiple installs, which is the only time they'd get in the situation i) Comment 32, they should have no problem understanding us being friendly and guiding them through creating or selecting an existing profile.

For someone that doesn't understand profiles, they create the profile once (that we helped guide them through), and they never need to remember about profiles again. The last used per binary path thing discussed previously kicks in after that.
By the way that was only my preference about not hiding profiles. If we really want to we can use the same idea as Comment 32 i) and when there are no other profiles just say "In order to start Nightly at the same time as Firefox, we need to keep track of your bookmarks and other information separately? [OK], [No way].  Behind the scenes it works the same way as discussed.
(In reply to Mark Hammond (:markh) from comment #33)
> 
> To put it another way: people should not be forced to learn about and deal
> with profiles just so they can safely run Aurora and Nightly.

I think you are missing a subset of users (mainly web developers) who don't want to go through troubles of managing multiple profiles but want to run Nightly and Stable channels of Firefox side-by-side. Just like web developers do with Chrome Stable and Chrome Canary. And this is the audience we're trying to cover.
(In reply to Mark Hammond (:markh) from comment #25)
> From my POV, this talk about waiting to help WebDevs (and also the
> discussion in
> https://wiki.mozilla.org/Features/Desktop/
> Ability_to_run_concurrent_channels) isn't particularly high-value for us. 
> We seem to be focusing on people who want to use Nightly for very quick
> drive-by tests of their own sites - which they should be doing already
> anyway for their own selfish reasons.

Drive-by tests happen today. That's how majority of web developers (at least at my previous company and those I meet at conferences) already use Firefox. We want them to use Firefox as their main development target which means providing them both stability of a browser and latest tools. You can achieve that today by juggling with -p but its a pain. My efforts are to reduce this barrier of entry.

> High-value for us is encouraging people to use Nightly/Aurora as "daily
> drivers" as much as possible.  For me, that means using my regular profile.

I don't think it is reasonable to expect all web developers to also be testers for our browser.
(In reply to Brian R. Bondy [:bbondy] from comment #35)
> By the way that was only my preference about not hiding profiles. If we
> really want to we can use the same idea as Comment 32 i) and when there are
> no other profiles just say "In order to start Nightly at the same time as
> Firefox, we need to keep track of your bookmarks and other information
> separately? [OK], [No way].  Behind the scenes it works the same way as
> discussed.

FTR, The more I think about it, I've come to the conclusion that this is actually the best solution I've seen so far that balances what we are trying to achieve with the amount of effort it will take.  There's another discussion on the firefox-dev list though which may or may not take a tangent...
tldr; high level summary of proposal discussed in this bug:

1. Keep track of last used profile per Firefox binary path
2. If process is already started, ask user if they'd like to fork a new profile, or open window in existing instance.
3. Make a profile manager (possibly w/ better UX) available from menu/jump list.

Use case A: User wants to use 2 browsers at once forever:
They get the message mentioned in #2 eventually, and they fork their profile.
#1 kicks in after that so they never see that UI again.

Use case B: We want a user to test something once:
They install Nightly build and they test it, we say to make sure to use the same profile:
i) If process from different binary is already started, they see #2 message. (Which is better than the current state of it simply opening an intance in the other process which I'm 100% sure has caused confusion to people in the past testing things).
ii) If process is not started, it uses last used profile.

Use case C: Release channel user needs a fix so we suggest to use beta:
i) They install beta and start using that instead of release. They see no extra UI because they aren't running both at the same time.

Use case D: Web developer want to test their site with Nightly once in a while:
i) They install Nightly, they'll eventually see #2 UI, in which case they can fork and only use that forked profile for Nightly thereafter.
what about for a mix of use cases B and D (or any of the others for that matter). If we have a one-shot profile fork/creation dialog, and they want to test a feature from their release profile, how do they reopen Nightly (or Aurora) and get back to their regular profile.

It seems like in all cases, you're going to get into a potential state where we have to open a Profile Manager.

Maybe that's fine. We're in that state currently where a user who wants to do one of these things is going to have to figure out the profile manager. I wonder if this doesn't suggest that we do a little work to augment and improve this piece of krufty interface from the Early Days?
(In reply to Rob Campbell [:rc] (:robcee) from comment #40)
> what about for a mix of use cases B and D (or any of the others for that
> matter). If we have a one-shot profile fork/creation dialog, and they want
> to test a feature from their release profile, how do they reopen Nightly (or
> Aurora) and get back to their regular profile.
> 

In my proposal a fork creation dialog would only appear if another instance is open from a different path. So if another browser isn't started they'd already be using their release profile. 

If another browser was open, we'd give the prompt and allow the user to fork it to open it at the same time. This would make the Nightly browser use the new Nightly, and the release channel use the same profile it always did. 

If they want to change which profile each browser is using, which would be rare, Comment 39 's #3 point covers accessing profile manager more easily.

If they manually set both browsers to use the same profile, when they tried to start them both again they'd get the same dialog prompt, but it would allow them to select from their available profiles or create a new one (i.e. profile manager).
If such a parallel launch was ever detected (and profiles were forked), instead of forcing the user to launch the profile manager (which may or may not go away), Firefox could add a menu item to e. g. the developers menu which lists the available profiles and allows to switch (and restart) to one of the others.
For what it's worth, I don't care if by default Firefox Nightly uses the main profile or a different one. What I do care about is to be able to assign Nightly/Aurora to separate profiles and make them use those profiles *always* when I start them using an icon in the Dock or in Launchpad.

Currently I have to open Aurora/Nightly from a command line which is inconvenient. Another options is to always open them using the Profile Manager - also inconvenient.

Even worse than inconvenience, if one day I forget to open them in one of these ways and I just click on an icon, I risk breaking my main Fx profile if sth goes wrong with this versions. That's really, really bad.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
Whi is this a duplicate of bug 1024110? That bug only enabled the feature for Firefox Developer Edition, there is still no checkbox to use separate profiles for Nightly...
I'd like this checkbox to appear in Nightly as well. And I'm pretty sure a lot of others, too!
Since this bug explicitly mentions Nightly, not Aurora/Developer Edition, I'm reopening it.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
I will add that there needs to be a bookmarks diff+mrge tool, it can be a separate application, although it would be OK too if it were built into the browser.
https://bugzilla.mozilla.org/show_bug.cgi?id=1116689
I would love this. This is the biggest reason I'm not using Nightly. I don't want to mess up my main Firefox profile. Developer Edition has this feature, so it would be great if Nightly had it too.
Status: REOPENED → RESOLVED
Closed: 10 years ago → 7 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: