While checking bug mail today I have seen a comment from Benjamin Smedberg on bug 278860 (https://bugzilla.mozilla.org/show_bug.cgi?id=278860) which is about the confusing profile manager warning when a profile is already in use. I was really upset when reading his statement in comment 91:
> In any case, I'm > trying to remove the profile manager in bug 214675, so I think this problem > will be mostly moot. >From bug 214675: > I want to do this for the 1.9.3 cycle. This removes a fair bit of complexity > from nsAppRunner.cpp and related code. This will help make it possible to > refactor all our startup code (XPCOM and toolkit) into a single place. It will > also make it possible to re-add a well-designed profile system like dmills > wants to do for Weave integration that doesn't require application restart.
Why do we want to remove the Profile Manager UI? It sounds insane, even with the knowledge that we do not have any alternative in place. So I have to ask: why is it useless? What about our user base? Do we know that much about everyone that we can make such an assumption? I don't think so. Instead having a private discussion on a bug we should talk about that issue in the public.
Given my QA point of view I would have to say that:
The profile manager is a component of Firefox we use heavily for testing. Most of us have a profile for each of our branches. Further other profiles exist for release testing and simply the daily checks. Given that existing profiles will be deleted and new ones created very often. Without an UI handling multiple profiles across branches will be a hassle because it would require us to have shortcuts for each and every of those profiles multiplied with the amount of branches installed. I do not think that everyone will handle profile data with the file manager.
Given the amount of bugs we triage over time a high percentage of those filed bugs we were able to solve after proposing ways like Safe Mode or creating a fresh profile. Having no UI anymore for profile management would make it harder for any user to handle their profiles.
Personally I have to use it a dozen of times per day while jumping between Minefield, Namoroka, Shiretoko, Gran Paradiso, and official releases. I believe that a huge amount of users seeing it the same way.
As already said above we shouldn't remove such a wide-spread feature without having anything else in place. We even don't know anything about the addressed profile system dmills wants to have and when it will be available - if it will be available.
Please don't do this.
my2c,
-- Henrik Skupin QA Execution Engineer Mozilla Corporation
> The profile manager is a component of Firefox we use heavily for > testing. Most of us have a profile for each of our branches. Further > other profiles exist for release testing and simply the daily checks.
If you just need one profile per browser executable, one way of doing this is to change the profile folder via application.ini's Name field (I know it's very hackish). It doesn't solve the other use cases, though.
> The profile manager is a component of Firefox we use heavily for > testing.
The problem with the alternative commandline solution is that the platform puts garbage characters in front of the profile name when it creates the profile directory. That means that you can't create new profile with -p foo, then go looking for "foo" in your directories.
> While checking bug mail today I have seen a comment from Benjamin > Smedberg on bug 278860 > (https://bugzilla.mozilla.org/show_bug.cgi?id=278860) which is about the > confusing profile manager warning when a profile is already in use. I > was really upset when reading his statement in comment 91:
>> In any case, I'm >> trying to remove the profile manager in bug 214675, so I think this problem >> will be mostly moot.
>> From bug 214675:
>> I want to do this for the 1.9.3 cycle. This removes a fair bit of complexity >> from nsAppRunner.cpp and related code. This will help make it possible to >> refactor all our startup code (XPCOM and toolkit) into a single place. It will >> also make it possible to re-add a well-designed profile system like dmills >> wants to do for Weave integration that doesn't require application restart.
> Why do we want to remove the Profile Manager UI? It sounds insane, even > with the knowledge that we do not have any alternative in place. So I > have to ask: why is it useless? What about our user base? Do we know > that much about everyone that we can make such an assumption? I don't > think so. Instead having a private discussion on a bug we should talk > about that issue in the public.
> Given my QA point of view I would have to say that:
> The profile manager is a component of Firefox we use heavily for > testing. Most of us have a profile for each of our branches. Further > other profiles exist for release testing and simply the daily checks. > Given that existing profiles will be deleted and new ones created very > often. Without an UI handling multiple profiles across branches will be > a hassle because it would require us to have shortcuts for each and > every of those profiles multiplied with the amount of branches > installed. I do not think that everyone will handle profile data with > the file manager.
> Given the amount of bugs we triage over time a high percentage of those > filed bugs we were able to solve after proposing ways like Safe Mode or > creating a fresh profile. Having no UI anymore for profile management > would make it harder for any user to handle their profiles.
> Personally I have to use it a dozen of times per day while jumping > between Minefield, Namoroka, Shiretoko, Gran Paradiso, and official > releases. I believe that a huge amount of users seeing it the same way.
> As already said above we shouldn't remove such a wide-spread feature > without having anything else in place. We even don't know anything about > the addressed profile system dmills wants to have and when it will be > available - if it will be available.
> Please don't do this.
> my2c,
QA spends quite a bit of time using the profile manager, and often even multiple profiles on the same build (-no-remote), to search and reproduce scenarios. Joshua, can your hack idea with application.ini work around this use case?
I think Henrik's point here is worth discussing as many of us from Mozilla QA have come to depend heavily on profile switching using this interface. I'm only speaking for Firefox, but i'm sure there are many other mozilla products that use Profile Manager and would love to chime in. Manual and automated testcases have been written with this component in mind, and that would mean having to adjust all of them if this went away. A new tool would need to be created in place, which means additional resources would be asked to step in to retain our current work environment with this component. While i understand the decision isnt' final of this archaic tool, and still a discussion within bug 214675, i'd like to know if there's a better place and time to lay out a justification and decision on why we really want to remove it.
>> The profile manager is a component of Firefox we use heavily for >> testing.
> The problem with the alternative commandline solution is that the > platform puts garbage characters in front of the profile name when it > creates the profile directory. That means that you can't create new > profile with -p foo, then go looking for "foo" in your directories.
Actually it is the profile UI that adds the garbage characters. Doing everything from the command line does not.
With the patch as suggested you will still be able to just run "firefox.exe -profile mydir" to point it to a directory to use for the profile.
FWIW, I actually think that we should be discussing this in dev.platform, not dev.planning, but here we are.
On 2010-01-12, at 5:09 PM, Henrik Skupin wrote:
>> I want to do this for the 1.9.3 cycle. This removes a fair bit of complexity >> from nsAppRunner.cpp and related code. This will help make it possible to >> refactor all our startup code (XPCOM and toolkit) into a single place. It will >> also make it possible to re-add a well-designed profile system like dmills >> wants to do for Weave integration that doesn't require application restart.
These sound like virtuous reasons. I should also note that the profile manager UI, as it exists, is literally the lowest potential bar and was meant to be removed from Firefox (see that bug's history) before v1.0 shipped.
Now, I'm a user of the Profile Manager, as are, I suspect, many Firefox developers. However, I recognize that we, as an aggregate group, represent not even a tenth of a percentage of our total user base. While I don't think anyone's arguing that we should retain the current system solely on the basis that it's very helpful for testers and developers, I do think that before this change is committed to the codebase, we should determine who will be affected and clearly communicate alternative pathways.
We may even wish to build a little application harness that replicates the function of the existing UI - that shouldn't be too hard to do, if I understand things correctly.
> Why do we want to remove the Profile Manager UI? It sounds insane, even > with the knowledge that we do not have any alternative in place. So I > have to ask: why is it useless? What about our user base? Do we know > that much about everyone that we can make such an assumption? I don't > think so. Instead having a private discussion on a bug we should talk > about that issue in the public.
Nobody has said it is useless, but it's clearly not a great tool that's suffered from underinvestment. If it's not very useful, and not used at all by the majority of our users (despite your question, I think we can assume that the vast majority of our users do not use a command-line-option required tool). It's lacking functionality that would be truly useful such as duplicating profiles, copying profiles, creating one-time-use profiles, and hasn't had any serious investment since it was created.
At the same time, there's a real cost in terms of our ability to modify the startup code pathways which may yield significant improvements in startup time. Taras has indicated that by removing the profile manager we will see an immediate and perceptible improvement in Ts, one of the metrics on which we compete.
> Given my QA point of view I would have to say that:
I've excised most of your original points here, and will instead summarize a set of requirements:
- the ability to manage a large set of profiles - the ability to choose a profile and branch of Firefox to launch - the ability for end users to reset their profile or create a new one
To that I'll add a bunch more requirements that I think would be even MORE useful for you:
- the ability to clone or duplicate a profile - the ability to create a one-time-use profile - the ability to generate a profile with certain default preferences or in a snapshot state - the ability to back up an entire profile - the ability to package a profile for migration to a new system - the ability to unpack a profile that's being migrated from an existing system
I think that most of these requirements can be bundled into an ancillary tool that are QA and tester focused and distributed separately (call it Firefox Starter's Gun), and some should be turned into tools that are available within the product for users (either as part of Safe Mode, or the main UI)
We can make these changes precursors to the actual removal of the code, or start projects so that the time that it will affect you and other testers on trunk will be short, at least.
Joshua Cranmer <Pidgeo...@verizon.net> wrote: > On 01/12/2010 05:09 PM, Henrik Skupin wrote: > > The profile manager is a component of Firefox we use heavily for > > testing. Most of us have a profile for each of our branches. Further > > other profiles exist for release testing and simply the daily > > checks.
> If you just need one profile per browser executable, one way of doing > this is to change the profile folder via application.ini's Name field > (I know it's very hackish). It doesn't solve the other use cases, > though.
I have a patch permanently at the bottom of my mq stack that does exactly this (among other things) so that I can have confidence that my development builds are never, ever exposed to any random crap that may be in my regular profile(s).
I would be most pleased if something like that became a ./configure option, although I don't imagine it would cover everything that the patch does. Normal people don't want the system extension directories forcibly disabled at compile time, for instance :-)
Tony Chung wrote: > On 1/12/10 2:09 PM, Henrik Skupin wrote: >> While checking bug mail today I have seen a comment from Benjamin >> Smedberg on bug 278860 >> (https://bugzilla.mozilla.org/show_bug.cgi?id=278860) which is about the >> confusing profile manager warning when a profile is already in use. I >> was really upset when reading his statement in comment 91:
>>> In any case, I'm >>> trying to remove the profile manager in bug 214675, so I think this >>> problem >>> will be mostly moot. >>[cut]
Even setting aside internal uses, making a new profile via the profile manager is a KEY troubleshooting step in support since it gives us a clean profile. Sorry to say but sometimes a user's profile is so broken that we just have to nuke everything, make a new profile and then recover the data we can (doubly so when Weave could potentially upstream missing data and thus propagating a localized disaster into a nightmare). It's also the only solution for users who want to run multiple instances of Firefox for different users/usecases without forcing a logout/login cycle. Lastly, there are tips sites all over the web that suggest multiple profiles for various tasks (I know Lifehacker does for example). I think we should find out if it's more popular than we think before we remove it. IF we were to do this (I'm not saying I like the current UI), I'd like to have: 1) some sort of better safe mode/data recovery mode that gives you clean places.sqlite etc. 2) Some alternative to have different users on the same Firefox install (Weave may be doing this) 3) Good, clear steps to help users who are currently running multiple profiles keep this functionality. (Maybe a tool that lets you make a shortcut for your other profiles on your desktop/in your start menu).
I'm not saying I like the current UI and that it's without its problems, I'm just saying it has specific and very important uses for our users (and not just us). Until we can replace these usecases with better alternatives, let's keep what we have.
If you need me to justify with concrete numbers I can find out how many times in a given week on LiveChat we help a user by using the profile manager compared to how many times we need to fix a problem caused by it. I suspect it's easily 5:1 or higher.
> On 01/12/2010 05:09 PM, Henrik Skupin wrote: >> The profile manager is a component of Firefox we use heavily for >> testing. Most of us have a profile for each of our branches. Further >> other profiles exist for release testing and simply the daily checks.
> If you just need one profile per browser executable, one way of doing > this is to change the profile folder via application.ini's Name field (I > know it's very hackish). It doesn't solve the other use cases, though.
I'm a user, not a developer. I have one instance of a browser installed. I have four profiles for that browser. Three of those profiles I use regularly; the fourth is for the use of guests who might not appreciate how I've configured the other three. Currently, I've been thinking of creating additional profiles for frequent visitors, a separate profile for each visitor.
Additionally, when I report a bug, your developers often ask me to create a whole new (but temporary) profile to test that bug further. If I don't have a user interface to create and delete profiles, my cooperation in that effort will cease.
Is bug #214675 for the benefit of end users or for the benefit of a few developers?
Don't ask "Why is there road rage?" Instead, ask "Why NOT Road Rage?" or "Why Is There No Such Thing as Fast Enough?" <http://www.rossde.com/roadrage.html>
On Jan 12, 7:38 pm, Mike Beltzner <beltz...@mozilla.com> wrote:
> I think that most of these requirements can be bundled into an ancillary tool that are QA and tester focused and distributed separately (call it Firefox Starter's Gun), and some should be turned into tools that are available within the product for users (either as part of Safe Mode, or the main UI)
> We can make these changes precursors to the actual removal of the code, or start projects so that the time that it will affect you and other testers on trunk will be short, at least.
> cheers, > mike
Since Netscape I've always wanted the ability to go into the Files dropdown menu and change profiles. As it is now, I have shortcuts that specify which profiles they go to. So, for me as a themes developer, I use the Profiles UI only if something gets bunged up and I have to fix it.
That said, a tool that is available "within the product" would be great. But like Mike, I wouldn't remove the old UI until a new tool has been debugged and is in use. Repeat - in use. Then the old UI can go.
> That said, a tool that is available "within the product" would be > great. But like Mike, I wouldn't remove the old UI until a new tool > has been debugged and is in use. Repeat - in use. Then the old UI can > go.
(sorry for the duplicate; cross-posting sucks for this precise reason)
That's been a misreading of what I said. I said that bugs should be filed for the development of the new features and tools, and alternative mechanisms of supporting the existing tasks should be documented, but certainly on mozilla-central we shouldn't delay changes that are required in order to move forward with our plans to improve startup time or better integration with Weave.
We obviously won't ship a product to users that regresses important functionality that our support teams rely on (as Cheng indicated), but I think we can ship nightly and development builds without a profile manager for a while as long as we correctly document how to achieve the same functionality with command line arguments.
> Given my QA point of view I would have to say that:
> The profile manager is a component of Firefox we use heavily for > testing. Most of us have a profile for each of our branches. Further > other profiles exist for release testing and simply the daily checks. > Given that existing profiles will be deleted and new ones created very > often. Without an UI handling multiple profiles across branches will be > a hassle because it would require us to have shortcuts for each and > every of those profiles multiplied with the amount of branches > installed. I do not think that everyone will handle profile data with > the file manager.
I'm not sure I understand your current workflow. You unpack/install/whatever a version of Firefox, and then you open a command line and run firefox.exe -P -no-remote to get to the profile manager? Or is it something less or more complicated?
There seem to be two issues in response:
* user support tasks of backing up/cleaning a profile * heavy-duty QA and other people who regularly use multiple profiles.
It seems to me that these two use cases present very different needs.
In terms of user support, it would be relatively easy and enjoyable to modify the current "safe mode" to provide additional options such as "back up my data" and "wipe all my data and start over fresh". I'm all for doing this, since by itself it doesn't cause a lot of complexity in the startup path. If these two options are insufficient, we should talk about what set of options would be sufficient, with the provision that I'd like to avoid exposing multiple profiles or the concept of profiles to end users as much as possible. It's just "my Firefox data", and the fact that we store in in with the label "default profile" is an implementation detail that can change (and is).
I've been treating the QA/multi-profile case with much less interest, primarily because if you're in that group, you are probably already comfortable with a command prompt, and `firefox -profile dir` is just as simple as `firefox -P`.
It's almost trivial to write a python script which presents a list of profiles/directories and selects one before launching Firefox (passing the directory in -profile), if that is somehow helpful. Would a python script from the command line solve the QA case sufficiently?
> Personally I have to use it a dozen of times per day while jumping > between Minefield, Namoroka, Shiretoko, Gran Paradiso, and official > releases. I believe that a huge amount of users seeing it the same way.
Why? We don't recommend that most people, even beta users, use different profiles for different releases: we *want* people to use the same profile as much as possible, so that upgrade/downgrade problems across branches get as much visibility as possible. I understand that QA may have different requirements than ordinary beta users, but I don't think we should extrapolate out to "a huge number of users". I think we've done a fairly effective job of hiding the profile manager so that it never appears unless you use the command line an explicitly ask for it.
> As already said above we shouldn't remove such a wide-spread feature > without having anything else in place. We even don't know anything about > the addressed profile system dmills wants to have and when it will be > available - if it will be available.
Other than I heard dmills wanted to do something with Weave and making it possible for multiple users to use the browser without conflicting, we should presume that *nothing* is planned in that department, and this removal is a standalone decision that was prompted by code complexity, serious bugs, and maintenance costs in the current profile manager.
Coming from the SeaMonkey side of things mostly, a lack of profile manager will hurt. But this is not about just a SeaMonkey consumer, its about all Gecko consumers, and have based my responses on the latter...
On 1/12/2010 7:38 PM, Mike Beltzner wrote:
> On 2010-01-12, at 5:09 PM, Henrik Skupin wrote:
>>> I want to do this for the 1.9.3 cycle. This removes a fair bit of complexity >>> from nsAppRunner.cpp and related code. This will help make it possible to >>> refactor all our startup code (XPCOM and toolkit) into a single place. It will >>> also make it possible to re-add a well-designed profile system like dmills >>> wants to do for Weave integration that doesn't require application restart.
> These sound like virtuous reasons. I should also note that the profile manager UI, as it exists, is literally the lowest potential bar and was meant to be removed from Firefox (see that bug's history) before v1.0 shipped.
> Now, I'm a user of the Profile Manager, as are, I suspect, many Firefox developers. However, I recognize that we, as an aggregate group, represent not even a tenth of a percentage of our total user base. While I don't think anyone's arguing that we should retain the current system solely on the basis that it's very helpful for testers and developers, I do think that before this change is committed to the codebase, we should determine who will be affected and clearly communicate alternative pathways.
> We may even wish to build a little application harness that replicates the function of the existing UI - that shouldn't be too hard to do, if I understand things correctly.
Building an application harness is ok, I'd love if XULRunner let you "generate" said harness when installing XULRunner apps though. (for those XULRunner apps that wish to make use of a profile manager)
>> Why do we want to remove the Profile Manager UI? It sounds insane, even >> with the knowledge that we do not have any alternative in place. So I >> have to ask: why is it useless? What about our user base? Do we know >> that much about everyone that we can make such an assumption? I don't >> think so. Instead having a private discussion on a bug we should talk >> about that issue in the public.
> Nobody has said it is useless, but it's clearly not a great tool that's suffered from underinvestment. If it's not very useful, and not used at all by the majority of our users (despite your question, I think we can assume that the vast majority of our users do not use a command-line-option required tool). It's lacking functionality that would be truly useful such as duplicating profiles, copying profiles, creating one-time-use profiles, and hasn't had any serious investment since it was created.
> At the same time, there's a real cost in terms of our ability to modify the startup code pathways which may yield significant improvements in startup time. Taras has indicated that by removing the profile manager we will see an immediate and perceptible improvement in Ts, one of the metrics on which we compete.
I can understand the Ts Cost, but even if the UI is far from ideal and not "used everyday by most users" at what point do we consider barrier to entry with downloading a seperate "app pack" (given also potential for users to be on LOCKED DOWN systems where they can't install an app pack; or in situations where any file that is downloaded and executeable can't be run, etc. that would prevent running FF profile manager entirely for troubleshooting/QA issues).
>> Given my QA point of view I would have to say that:
> I've excised most of your original points here, and will instead summarize a set of requirements:
> - the ability to manage a large set of profiles > - the ability to choose a profile and branch of Firefox to launch > - the ability for end users to reset their profile or create a new one
These are good as a "must have". and imo, without them the product is BARELY qualifyable as dogfoodable as a dev.
> To that I'll add a bunch more requirements that I think would be even MORE useful for you:
> - the ability to clone or duplicate a profile > - the ability to create a one-time-use profile > - the ability to generate a profile with certain default preferences or in a snapshot state > - the ability to back up an entire profile > - the ability to package a profile for migration to a new system > - the ability to unpack a profile that's being migrated from an existing system
These would be wonderful features and additions... but some of these actions are probably app-dependant and would need app-specific potential extensibility (TB, XULRunner apps, etc.) [for: backup, package... etc.]
> I think that most of these requirements can be bundled into an ancillary tool that are QA and tester focused and distributed separately (call it Firefox Starter's Gun), and some should be turned into tools that are available within the product for users (either as part of Safe Mode, or the main UI)
> We can make these changes precursors to the actual removal of the code, or start projects so that the time that it will affect you and other testers on trunk will be short, at least.
I would be happy to "make these changes precursors to the actual removal of the code, ... on trunk". If we however simply "file bugs, remove the code and wait... just simply blocking final release on a package "being available" it will hurt too much to even consider any trunk development or work for me, in the foreseeable future.
Two requirements I would like to make on the actual removal of this code: -Patch[es] to make the first of those first three requirements as you summarized possible, even if seperate app. with a configure option to m-c that allows us to build said seperate app in a normal build (if not built by default) and distribute with normal nightlies (RC's etc, are another story imo). -Have said patch ready within a week of the profile manager UI to ensure trunk stays easily dogfoodable for the rest of us, with the promise of either a m-c-wide freeze, or backout of profile-code-removal if not ready. [I seem to remember a requirement of "days away from release" for m-c going forward tossed around a lot].
>> Given my QA point of view I would have to say that:
>> The profile manager is a component of Firefox we use heavily for >> testing. Most of us have a profile for each of our branches. Further >> other profiles exist for release testing and simply the daily checks. >> Given that existing profiles will be deleted and new ones created very >> often. Without an UI handling multiple profiles across branches will be >> a hassle because it would require us to have shortcuts for each and >> every of those profiles multiplied with the amount of branches >> installed. I do not think that everyone will handle profile data with >> the file manager.
> I'm not sure I understand your current workflow. You > unpack/install/whatever a version of Firefox, and then you open a > command line and run firefox.exe -P -no-remote to get to the profile > manager? Or is it something less or more complicated?
> There seem to be two issues in response:
> * user support tasks of backing up/cleaning a profile > * heavy-duty QA and other people who regularly use multiple profiles.
I think its unlikely that users that share a computer will be showing up in this newsgroup to advocate for a feature they use everyday. If you do a bit of hunting you find quite a few articles like this
> It seems to me that these two use cases present very different needs.
> In terms of user support, it would be relatively easy and enjoyable to > modify the current "safe mode" to provide additional options such as > "back up my data" and "wipe all my data and start over fresh". I'm all > for doing this, since by itself it doesn't cause a lot of complexity > in the startup path. If these two options are insufficient, we should > talk about what set of options would be sufficient, with the provision > that I'd like to avoid exposing multiple profiles or the concept of > profiles to end users as much as possible. It's just "my Firefox > data", and the fact that we store in in with the label "default > profile" is an implementation detail that can change (and is).
> I've been treating the QA/multi-profile case with much less interest, > primarily because if you're in that group, you are probably already > comfortable with a command prompt, and `firefox -profile dir` is just > as simple as `firefox -P`.
> It's almost trivial to write a python script which presents a list of > profiles/directories and selects one before launching Firefox (passing > the directory in -profile), if that is somehow helpful. Would a python > script from the command line solve the QA case sufficiently?
>> Personally I have to use it a dozen of times per day while jumping >> between Minefield, Namoroka, Shiretoko, Gran Paradiso, and official >> releases. I believe that a huge amount of users seeing it the same way.
> Why? We don't recommend that most people, even beta users, use > different profiles for different releases: we *want* people to use the > same profile as much as possible, so that upgrade/downgrade problems > across branches get as much visibility as possible. I understand that > QA may have different requirements than ordinary beta users, but I > don't think we should extrapolate out to "a huge number of users". I > think we've done a fairly effective job of hiding the profile manager > so that it never appears unless you use the command line an explicitly > ask for it.
>> As already said above we shouldn't remove such a wide-spread feature >> without having anything else in place. We even don't know anything about >> the addressed profile system dmills wants to have and when it will be >> available - if it will be available.
> Other than I heard dmills wanted to do something with Weave and making > it possible for multiple users to use the browser without conflicting, > we should presume that *nothing* is planned in that department, and > this removal is a standalone decision that was prompted by code > complexity, serious bugs, and maintenance costs in the current profile > manager.
> I think its unlikely that users that share a computer will be showing up > in this newsgroup to advocate for a feature they use everyday. If you do > a bit of hunting you find quite a few articles like this
> some solution for these kinds of use cases seems appropriate.
There are lots of things that might be good, if we had infinite amounts of time. But we have repeatedly and consistently said, since Firefox 0.9 or so, that GUI management of multiple profiles is not a use case that we actively support, precisely because doing it right would require lots of work.
I believe in having UI so that SUMO can solve end-user problems effectively. I believe in making sure QA can still function. I don't think that "5700 people want the profile manager the way netscape had it" is a good argument for keeping this UI.
>>> I want to do this for the 1.9.3 cycle. This removes a fair bit of complexity >>> from nsAppRunner.cpp and related code. This will help make it possible to >>> refactor all our startup code (XPCOM and toolkit) into a single place. It will >>> also make it possible to re-add a well-designed profile system like dmills >>> wants to do for Weave integration that doesn't require application restart.
> These sound like virtuous reasons. I should also note that the profile manager UI, > as it exists, is literally the lowest potential bar and was meant to be removed > from Firefox (see that bug's history) before v1.0 shipped.
> Now, I'm a user of the Profile Manager, as are, I suspect, many Firefox developers. > However, I recognize that we, as an aggregate group, represent not even a tenth of > a percentage of our total user base. While I don't think anyone's arguing that we > should retain the current system solely on the basis that it's very helpful for > testers and developers, I do think that before this change is committed to the > codebase, we should determine who will be affected and clearly communicate alternative > pathways.
Not only for developers and QAs, for community user support some flow-charts including some test with creating a completely new profile using profile manager. Mainly for extensions, but it IS really useful to distinguish what is the problem. This might be the flow only in Japan, I don't know for others, I want to say that every existing scheme might be used in as-yet-unknown way for developers.. # like xul darkmatter? :-p
Masayuki, developer in Mozilla Japan, once said that it might be ok with asking 'renaming' Firefox directory including profiles (mostly parent of the profiles), but I think it is difficult for some low-skilled users to search its path. So, I'd rather like to have some UI to manage them in Firefox itself or in its safe mode.
On Tuesday 2010-01-12 22:22 -0500, Benjamin Smedberg wrote:
> I've been treating the QA/multi-profile case with much less > interest, primarily because if you're in that group, you are > probably already comfortable with a command prompt, and `firefox > -profile dir` is just as simple as `firefox -P`.
I think some people may not be fully aware of the -profile option, so I want to point out two things explicitly (especially the second, which I realized at least one person didn't know based on an in-person conversation earlier today):
* -profile <directory> lets you use an alternate profile in a manner similar to -P <profilename>, except that its argument is the location of the profile directory rather than the name of the profile within the standard profile directory location
* Using -profile <directory> on an empty directory makes Firefox create a new profile in that directory.
> On 1/12/2010 9:14 PM, Ed Hume wrote: >> That said, a tool that is available "within the product" would be >> great. But like Mike, I wouldn't remove the old UI until a new tool >> has been debugged and is in use. Repeat - in use. Then the old UI can >> go.
> (sorry for the duplicate; cross-posting sucks for this precise reason)
> That's been a misreading of what I said. I said that bugs should be > filed for the development of the new features and tools, and alternative > mechanisms of supporting the existing tasks should be documented, but > certainly on mozilla-central we shouldn't delay changes that are > required in order to move forward with our plans to improve startup time > or better integration with Weave.
> We obviously won't ship a product to users that regresses important > functionality that our support teams rely on (as Cheng indicated), but I > think we can ship nightly and development builds without a profile > manager for a while as long as we correctly document how to achieve the > same functionality with command line arguments.
Glancing at the patch, we'd still be reading profiles.ini. I kinda like the idea of not having to remember salted profile directory names, or having to cd to some special directory, could we keep the profile name piece around on the command line (i.e. -P debug)? Sounds like that'd not really have a major impact on the remaining code and its complexity. We can postpone adding stuff to profiles.ini for an external tool (like vi, for the meantime), I guess that most test infrastructure would work with an explicit path anyway.
Nit, you probably didn't want to comment out SOURCE_STAMP in the patch, Benjamin?
As a clarification, Benjamin, do you expect a TS win here? I don't know how much of the removed code is migration, and whether Taras actually tried his stuff with killing profiles.ini.
> On Tue, Jan 12, 2010 at 11:49 PM, Benjamin Smedberg > <benja...@smedbergs.us> wrote: >> On 1/12/10 11:32 PM, L. David Baron wrote:
>>> * Using -profile<directory> on an empty directory makes Firefox >>> create a new profile in that directory.
>> FWIW, this last bit is a new feature added to mozilla-central fairly >> recently... I don't think it has made it to the stable branches.
> Worked fine in 3.5, and I think before, you just had to create the > directory beforehand. Do you mean that central creates if ENODIR now?
Oh, yes. To clarify:
On all branches, you can `mkdir myprofile; firefox -profile myprofile` and it will launch and use myprofile as a new profile directory.
on mozilla-central you don't even make to make the directory in advance: you can just `firefox -profile myprofile` and if the myprofile directory doesn't exist it will be created.
>> I think its unlikely that users that share a computer will be showing up >> in this newsgroup to advocate for a feature they use everyday. If you do >> a bit of hunting you find quite a few articles like this
>> some solution for these kinds of use cases seems appropriate.
> There are lots of things that might be good, if we had infinite > amounts of time. But we have repeatedly and consistently said, since > Firefox 0.9 or so, that GUI management of multiple profiles is not a > use case that we actively support, precisely because doing it right > would require lots of work.
How much time and effort has been invested in 'supporting' multiple profiles since 0.9?
How many current Firefox users share a computer and use the feature?
Knowing those two basic things would help to get to a better cost/benefit assesment of the feature.
I'm guessing the population of people that share a single PC, but still want to take advantage of a key feature of Firefox which is the ability to customize it for personal preferences, is growing as Firefox. Its growing as Firefox reaches out to beyond an earlier adopter audience, and its growing in markets where technology is in earlier stages of adoption and fewer PCs are available per user.
That is the kind of research that is probably needed before making investments to yanking out this feature, or investing in improving the feature it really needs fixing.
> I believe in having UI so that SUMO can solve end-user problems > effectively. I believe in making sure QA can still function. I don't > think that "5700 people want the profile manager the way netscape had > it" is a good argument for keeping this UI.
The search results probably don't reflect 5700 people. They document a use case, and people sharing a solution they found valuable. Its the viewers of the lifehacker another similar pages, the digg hits for these pages, and some other metrics and surveys would be the kinds of things looked at if we were interested in figuring out what the product needs are for this area are.
> While checking bug mail today I have seen a comment from Benjamin > Smedberg on bug 278860 > (https://bugzilla.mozilla.org/show_bug.cgi?id=278860) which is about the > confusing profile manager warning when a profile is already in use. I > was really upset when reading his statement in comment 91:
>> In any case, I'm >> trying to remove the profile manager in bug 214675, so I think this problem >> will be mostly moot.
>>From bug 214675:
>> I want to do this for the 1.9.3 cycle. This removes a fair bit of complexity >> from nsAppRunner.cpp and related code. This will help make it possible to >> refactor all our startup code (XPCOM and toolkit) into a single place. It will >> also make it possible to re-add a well-designed profile system like dmills >> wants to do for Weave integration that doesn't require application restart.
> Why do we want to remove the Profile Manager UI? It sounds insane, even > with the knowledge that we do not have any alternative in place. So I > have to ask: why is it useless? What about our user base? Do we know > that much about everyone that we can make such an assumption? I don't > think so. Instead having a private discussion on a bug we should talk > about that issue in the public.
> Given my QA point of view I would have to say that:
> The profile manager is a component of Firefox we use heavily for > testing. Most of us have a profile for each of our branches. Further > other profiles exist for release testing and simply the daily checks. > Given that existing profiles will be deleted and new ones created very > often. Without an UI handling multiple profiles across branches will be > a hassle because it would require us to have shortcuts for each and > every of those profiles multiplied with the amount of branches > installed. I do not think that everyone will handle profile data with > the file manager.
> Given the amount of bugs we triage over time a high percentage of those > filed bugs we were able to solve after proposing ways like Safe Mode or > creating a fresh profile. Having no UI anymore for profile management > would make it harder for any user to handle their profiles.
> Personally I have to use it a dozen of times per day while jumping > between Minefield, Namoroka, Shiretoko, Gran Paradiso, and official > releases. I believe that a huge amount of users seeing it the same way.
> As already said above we shouldn't remove such a wide-spread feature > without having anything else in place. We even don't know anything about > the addressed profile system dmills wants to have and when it will be > available - if it will be available.
> Please don't do this.
> my2c,
All the comments in this thread about command line options ignore the fact that (1) end users do indeed use the Profile Manager and (2) command line options are not user-oriented, especially for non-expert Windows users.
Don't ask "Why is there road rage?" Instead, ask "Why NOT Road Rage?" or "Why Is There No Such Thing as Fast Enough?" <http://www.rossde.com/roadrage.html>
On Tue, Jan 12, 2010 at 9:50 PM, David E. Ross <nob...@nowhere.invalid>wrote:
> All the comments in this thread about command line options ignore the > fact that (1) end users do indeed use the Profile Manager and (2) > command line options are not user-oriented, especially for non-expert > Windows users.
Currently, there's no way to bring up the profile manager itself without invoking FF without using the command line, is there? (I'm talking about the first time, subsequent times you can uncheck the box and make Profile Manager show up every time, of course)
-- Alexander Limi · Firefox User Experience · http://limi.net
On 13 Jan, 05:05, chris hofmann <chofm...@meer.net> wrote:
> How much time and effort has been invested in 'supporting' multiple > profiles since 0.9?
> How many current Firefox users share a computer and use the feature?
> Knowing those two basic things would help to get to a better > cost/benefit assesment of the feature.
I don't really care about the answer to these questions. The real important question to me that profiles is the answer these days is:
How do I know if a problem is with Firefox, an extension or broken user data?
If the profile manager is removed, I have no way of getting an answer to this from a remote user supported through email from the community. These days, I give people that say their Firefox is broken the instructions to create a new profile and ask for feedback. This is invaluable, because reinstalling Firefox when the profile is broken is useless (Firefox continues to fail, in the user's eyes).
My experience is that in support people will only believe you if things are working. This means that, unless I can "show" them a working profile, they won't believe the problem is somewhere else and not in Firefox.
Please, do not remove profile manager unless you have an answer to the above question.
