Removal of the Profile Manager UI?

115 views
Skip to first unread message

Henrik Skupin

unread,
Jan 12, 2010, 5:09:09 PM1/12/10
to
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

Joshua Cranmer

unread,
Jan 12, 2010, 5:38:25 PM1/12/10
to
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.

John J Barton

unread,
Jan 12, 2010, 6:29:11 PM1/12/10
to
Henrik Skupin wrote:
>
> 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.

jjb

Tony Chung

unread,
Jan 12, 2010, 6:30:30 PM1/12/10
to

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.

crossposting to mozilla.dev.platform

Tony

Dave Townsend

unread,
Jan 12, 2010, 6:40:08 PM1/12/10
to

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.

Mike Beltzner

unread,
Jan 12, 2010, 7:38:19 PM1/12/10
to Henrik Skupin, mozilla.dev.planning group, dev-pl...@lists.mozilla.org
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.

cheers,
mike

Zack Weinberg

unread,
Jan 12, 2010, 7:32:24 PM1/12/10
to dev-pl...@lists.mozilla.org
Joshua Cranmer <Pidg...@verizon.net> wrote:

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 :-)

zw

Cheng Wang

unread,
Jan 12, 2010, 8:41:53 PM1/12/10
to Tony Chung
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.

Cww.

David E. Ross

unread,
Jan 12, 2010, 8:57:38 PM1/12/10
to

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?

--

David E. Ross
<http://www.rossde.com/>.

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>

Ed Hume

unread,
Jan 12, 2010, 9:14:10 PM1/12/10
to
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.

Mike Beltzner

unread,
Jan 12, 2010, 9:34:22 PM1/12/10
to dev-pl...@lists.mozilla.org, dev-pl...@lists.mozilla.org
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.

cheers,
mike

Benjamin Smedberg

unread,
Jan 12, 2010, 10:22:22 PM1/12/10
to
On 1/12/10 5:09 PM, Henrik Skupin wrote:

> 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.

--BDS

Justin Wood (Callek)

unread,
Jan 12, 2010, 10:29:28 PM1/12/10
to
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].

-
~Justin Wood (Callek)

chris hofmann

unread,
Jan 12, 2010, 10:47:35 PM1/12/10
to dev-pl...@lists.mozilla.org

On 1/12/10 7:22 PM, Benjamin Smedberg wrote:
> On 1/12/10 5:09 PM, Henrik Skupin wrote:
>
>> 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

http://lifehacker.com/231646/geek-to-live--manage-multiple-firefox-profiles
http://ahtim.com/create-multi-user-profiles-in-firefox/

google says there is something like 5700 more pages like this
http://www.google.com/search?hl=en&q=%22firefox+multiple+users%22&aq=f&oq=&aqi=

some solution for these kinds of use cases seems appropriate.

-chofmann

> _______________________________________________
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning

Benjamin Smedberg

unread,
Jan 12, 2010, 11:14:05 PM1/12/10
to
On 1/12/10 10:47 PM, chris hofmann wrote:

> 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
>
> http://lifehacker.com/231646/geek-to-live--manage-multiple-firefox-profiles
> http://ahtim.com/create-multi-user-profiles-in-firefox/
>
> google says there is something like 5700 more pages like this
> http://www.google.com/search?hl=en&q=%22firefox+multiple+users%22&aq=f&oq=&aqi=
>
>
> 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.

--BDS

Atsushi Shimono

unread,
Jan 12, 2010, 11:23:44 PM1/12/10
to mozilla.dev.planning group, dev-pl...@lists.mozilla.org, Henrik Skupin
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

hi,

(2010/01/13 9:38), Mike Beltzner 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.

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.


just $.02
- --
Atsushi Shimono
mail : shimono @ gmail.com / mixi id : 7708 / http://blog.himor.in/
skype : shimono_univ (w/cam) / http://facebook.com/himorin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)

iQIcBAEBCgAGBQJLTUrOAAoJEHI5evwJBSZd+d4QAKZSOeDzcNqBpI9nICewT/rf
PzY+aDwZGTQYkp9g0zU91k7TKqzi2gU9B8Nq9Rb9xOI4247++fLcMFiWZRqW9/tc
H3RzprhmOL2aGzHP37L6MdCltrmKZ9/F2JZ+9rg/xluCTQi5pNpqYowtWqGPLW1G
kIfuxMyT0WE7ctHzM/qq3IENmlPpBh9c7hyZ2FxjkoMwAGzTsYtbXtbzUAvV6HVx
e5lq9q4vxW92SvecKRLdN+84yNUECyyBJiSJU99Q0qAC6hj3GpUfBcHltowWAk9N
3LFjRZJrP3RQdBaE4D51Y8w1ohVQ2RrcGam22Y5vfRCGxK3DNWW6pmONrd32jtGd
U0i8GnOB0Y9b2A6Xn4S7enReWMiKBSHN8jb2fwyeH9k12DmKsxYV627KDRKvaIoQ
LL5PLkU6cfmem+Ue7HTTaCHW96ttPBogzXSMIPjimrUPFDAcUHKXahL21KmaypqB
hFbYEGxSV/GxJUdwsaHi82mUMSaxBWP6kbOVgijY91yoA/bYMItX0hvRwilEj0yn
oLLnjms614l/4tO2w3GZRxPpw/0mkbMBw46HNr25Huvlm/dCib4i45m2hI7eq5rs
i1/SpdR4gYVDfMhtzmJ4/KqOFsvTJ56CbQu6LsMK3DTwyo2d5jT7RO4b212y08u8
pAH++Yyb9T99YZ0I5W+N
=uVf4
-----END PGP SIGNATURE-----

L. David Baron

unread,
Jan 12, 2010, 11:32:48 PM1/12/10
to dev-pl...@lists.mozilla.org
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.

-David

--
L. David Baron http://dbaron.org/
Mozilla Corporation http://www.mozilla.com/

Benjamin Smedberg

unread,
Jan 12, 2010, 11:49:36 PM1/12/10
to
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.

--BDS

Axel Hecht

unread,
Jan 13, 2010, 12:02:32 AM1/13/10
to
On 13.01.10 03:34, Mike Beltzner wrote:
> 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.

Axel

Benjamin Smedberg

unread,
Jan 13, 2010, 12:04:37 AM1/13/10
to
On 1/12/10 11:53 PM, Mike Shaver wrote:
> 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.

--BDS

chris hofmann

unread,
Jan 13, 2010, 12:05:38 AM1/13/10
to dev-pl...@lists.mozilla.org
On 1/12/10 8:14 PM, Benjamin Smedberg wrote:
> On 1/12/10 10:47 PM, chris hofmann wrote:
>
>> 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
>>
>> http://lifehacker.com/231646/geek-to-live--manage-multiple-firefox-profiles
>>
>> http://ahtim.com/create-multi-user-profiles-in-firefox/
>>
>> google says there is something like 5700 more pages like this
>> http://www.google.com/search?hl=en&q=%22firefox+multiple+users%22&aq=f&oq=&aqi=
>>
>>
>>
>> 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.

-chofmann

L. David Baron

unread,
Jan 13, 2010, 12:10:02 AM1/13/10
to dev-pl...@lists.mozilla.org

This has worked back to Firefox 1.0.*, and probably before.

(Note that I said *empty* directory; I'm used to having to run
"mkdir <dirname>" first.)

David E. Ross

unread,
Jan 13, 2010, 12:50:36 AM1/13/10
to

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.

Alexander Limi

unread,
Jan 13, 2010, 1:33:09 AM1/13/10
to dev-pl...@lists.mozilla.org
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

João Miguel Neves

unread,
Jan 13, 2010, 5:12:35 AM1/13/10
to
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.

Best regards,
João Miguel Neves

Martin Freitag

unread,
Jan 13, 2010, 5:59:47 AM1/13/10
to
David E. Ross schrieb:

> On 1/12/2010 2:38 PM, Joshua Cranmer wrote:
> 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.

ACK.

regards
Martin
--
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - http://www.asciiribbon.org/index-de.html

Henrik Skupin

unread,
Jan 13, 2010, 6:52:19 AM1/13/10
to
L. David Baron wrote on 13.01.10 05:32:

> * Using -profile <directory> on an empty directory makes Firefox
> create a new profile in that directory.

But therefor the directory has to be created first and resetting a
profile requires to delete profile data manually.

Henrik

Henrik Skupin

unread,
Jan 13, 2010, 6:58:46 AM1/13/10
to
Benjamin Smedberg wrote on 13.01.10 06:04:

> 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.

That one is nice. Thanks for sharing. Do you have the bug # off-hand?

Henrik

Dao

unread,
Jan 13, 2010, 7:00:42 AM1/13/10
to

You can also modify the target location of the desktop shortcut.

The sentence in parentheses is pretty important. It allows you to follow
some simple instructions you don't fully understand and then forget
about it. And even if you did understand the instructions, you wouldn't
want to repeat them each time you launch Firefox.

Wayne Mery

unread,
Jan 13, 2010, 10:51:25 AM1/13/10
to
On 1/12/2010 11:14 PM, Benjamin Smedberg wrote:
> On 1/12/10 10:47 PM, chris hofmann wrote:
>
>> 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
>>
>> http://lifehacker.com/231646/geek-to-live--manage-multiple-firefox-profiles
>>
>> http://ahtim.com/create-multi-user-profiles-in-firefox/
>>
>> google says there is something like 5700 more pages like this
>> http://www.google.com/search?hl=en&q=%22firefox+multiple+users%22&aq=f&oq=&aqi=
>>
>>
>>
>> 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.

Yes, it has been a longstanding, consistent message. However, "we",
afaik, has been a few voices.

It has also been stated one reason justifying removal is that profile
manager has not received much coding or other attention - that's a fact.
But changes/improvements have been actively discouraged and iirc patches
or proposed changes disapproved ... catch 22. And why, FINALLY, this
we're having a good conversation on how to do better.

That said, I don't disagree that changes are needed, and that the
backend startup code must move forward.


--
http://wiki.mozilla.org/Thunderbird:Testing
http://www.spreadthunderbird.com/aff/165/

Phillip Jones

unread,
Jan 13, 2010, 11:05:48 AM1/13/10
to
David E. Ross wrote:
> On 1/12/2010 2:38 PM, Joshua Cranmer 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'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?
>
Most likely for the developers.

--
Phillip M. Jones, C.E.T. "If it's Fixed, Don't Break it"
http://www.phillipmjones.net http://www.vpea.org
mailto:pjo...@kimbanet.com

S. Beaulieu

unread,
Jan 13, 2010, 11:06:46 AM1/13/10
to
End user chiming in. I don't have a single developer bone in me.

chris hofmann a �crit :


>
> How many current Firefox users share a computer and use the feature?

Everyone I know who shares a family computer. The profile manager is a
major feature in such situations. Anecdotal, for sure, but I don't think
the people I know and I are that special.

Also, it makes managing shared computers a breeze at work (I do that).
And I am certain my company isn't that much different from other ones.


>
> 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.

Precisely.

I think B. Smedberg underestimates how many end-users rely on this
feature everyday. Not to mess with profiles per se or to test anything,
but simply to allow more than one person to share a computer without
having to create various accounts for it. Customizability is a key point
in FF and SM, and the profile manager is a necessary part for it.

So no, it's not just "my Firefox data": it's "my Firefox data as opposed
to someone else with whom I share a computer's Firefox data".

Forcing basic end-users to switch to command line is not an option. They
will simply lose the ability to use a feature they have come to rely to.

Doing away with the UI would not be an improvement, but a step back.

S.

RyanVM

unread,
Jan 13, 2010, 11:22:28 AM1/13/10
to
Another end user/community member chiming in here. I use the profile
manager both as a way for my wife and I to share computers and as a
testing tool.

On the computer sharing side of things, what other options are there
other than multiple user accounts on the computer? And doesn't that
seem a wee bit overkill when all we're looking to accomplish is to
have our own separate Firefox profiles? I understand the system well
enough that we'll adapt if need-be (multiple shortcuts pointing to
different profiles), but it's not difficult for me to see less-
familiar users having no clue how to do that. Most don't even
understand how shortcuts work.

From a testing standpoint, I maintain a separate, clean, no-frills
testing profile that I can use when I want a "clean room" profile in
order to ensure no cross-contamination. I worry about using safe-mode
in lieu due to the risk of inadvertently making permanent changes to
the profile with the current safe-mode UI. It's not outside the realm
of possibility to accidentally leave something checked and end up
clearing data you didn't mean to clear.

If the profile manager is ultimately set to be removed, I would surely
hope that another system for managing profiles be in place prior to
removal. Otherwise, I think it's just asking for pushback from a set
of dedicated users that's already been feeling ignored lately by the
storm over Personas/Jetpack.

Phillip Jones

unread,
Jan 13, 2010, 11:29:25 AM1/13/10
to


Note this may be a duplicate post: I had to restart SeaMonkey after
posting so bare with me:

Can anyone provide a sane reason for the possibility of removing Profile
Manager?

What about the case where you use a Profile and need to test for a
problem by
creating another.

Or a person might want to use a different profile say if they used two
different ISP and or services.

I am Mac User and yes I can set up different System Profiles on my
Computer. but that
means I have to do multiple installs of other applications Word, Quicken,
Acrobat, etc. and the have licenses that do not permit installing more
than one
copy on a Desktop, laptop and on a Back up media.

If people are not smart enough to not accidentally create multiple
Profiles,
that's their problem.

I've been using Mozilla Products since the days of Netscape Navigator
3.0.1.a
Gold and I've never *accidentally* created a new profile. In fact the
way Profile Manager is set up on SM and FF for mac it impossible to
accidentally do so.

Sounds like people are just getting lazy and don't want to maintain the
code,
or just don't want to port over to new code before people leave that
have the
ability. I don't know why people want to take a good product and damage
it just
because they are unwilling to work on it. (To more Emulate Emulate IE I
guess

The arguments about speed increases. what will it do shave 1 or 2 tenths
or hundreds of seconds off of Launch? All justified by dumping a
Valuable tool.

Another example of not caring about the end user. and just satisfying
the wants and needs of the developers.

Philip Chee

unread,
Jan 13, 2010, 12:33:53 PM1/13/10
to
On Tue, 12 Jan 2010 19:38:19 -0500, Mike Beltzner wrote:

The SeaMonkey project would certainly like to retain our Profile Manager
UI. While parts of it are forked, I hope that the backend that it
depends on would remain intact.

> 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

These last three items would be useful to our endusers as well as the
developer, QA, and tester communities.

> 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 do hope that this will be the case.

Phil

--
Philip Chee <phi...@aleytys.pc.my>, <phili...@gmail.com>
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.
[ ]A yer ago I kudnt spel progremr now I are won.
* TagZilla 0.066.6

Philip Chee

unread,
Jan 13, 2010, 12:38:55 PM1/13/10
to
On Tue, 12 Jan 2010 18:14:10 -0800 (PST), Ed Hume wrote:

> 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.

The Mozilla Suite and SeaMonkey have never lost the Tools->Switch
Profile... option. Our user base would be extraordinarily annoyed at us
(as opposed to the constant low level background annoyance levels at the
moment).

Henrik Skupin

unread,
Jan 13, 2010, 12:40:08 PM1/13/10
to
Benjamin Smedberg wrote on 13.01.10 04:22:

> 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?

I always try to limit the command line access as much as possible.
Firefox installations always have a fixed location on my box so I can
easily add shortcuts to the dock or the quicklaunch bar. All of those
shortcuts (Windows and Linux) have the -no-remote option added. I do not
bind each of the versions with a given profile at this time. Depending
on the task I have to execute I select the appropriate profile via the
profile manager ui during startup.

> 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`.

Having to use the command line for profile selection I would have to
remember the exact names and locations on disk. Not that I wouldn't be
able to remember that information but the ui helps here a lot - it's
just a single click to start with the correct profile.

> 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?

QA would have to discuss that. Do you mean that we can use the Python
script as a temporary solution before the other tool will be ready for use?

> 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

I could give a couple of examples. The most important ones are simply
the changes we had for the back-end storage where we moved from text
files to sqlite3 and do only support a migration for the first run.
Later additions will not be synced and you will end up in two different
places with your data saved. Further the tests on Litmus are run mostly
against a fresh profile. Those are Smoketests, BFTs, FFTs, and the
software update tests. Only for major updates we explicitly use mixed
profiles.

> 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.

Support and QA are offering those steps on bugs to help investigating a
newly filed issue. You are right that we cannot extrapolate out a "huge
number of users" but we can also not say that only a tiny amount of
users are aware of the profile manager and even use it. I'm sorry for
having that said.

Henrik

Benjamin Smedberg

unread,
Jan 13, 2010, 1:17:13 PM1/13/10
to
On 1/13/10 12:40 PM, Henrik Skupin wrote:

>> 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?
>
> QA would have to discuss that. Do you mean that we can use the Python
> script as a temporary solution before the other tool will be ready for use?

There is no other proposed tool, unless I'm misreading. No, I mean that it
would be a permanent solution.

> Support and QA are offering those steps on bugs to help investigating a
> newly filed issue. You are right that we cannot extrapolate out a "huge

That is the support question, which I proposed to solve with a profile
backup/restore/wipe mechanism from the safe-mode dialog. If
backup/restore/wipe is not a sufficient mechanism for support purposes, then
let's figure out why not.

--BDS

Benjamin Smedberg

unread,
Jan 13, 2010, 1:22:17 PM1/13/10
to
On 1/13/10 12:33 PM, Philip Chee wrote:

> The SeaMonkey project would certainly like to retain our Profile Manager
> UI. While parts of it are forked, I hope that the backend that it
> depends on would remain intact.

As noted in the bug, or here, or something, Neil and I discussed the
possibility of maintaining profile management functionality outside of
XRE_main, and that should be possible, if you're also willing to maintain
the restart logic that needs to go with it.

The whole point of this exercize is to remove the backend to the point where
we can make significant improvements to the startup sequence.

For the record, I'm currently completely absorbed with loretnz and OOPP, and
so this bug is not something that was meant for imminent checkin, and I
haven't even seriously discussed it with Mossop, so the imminent angst is
probably out of place.

--BDS

Philip Chee

unread,
Jan 13, 2010, 1:42:02 PM1/13/10
to
On Wed, 13 Jan 2010 13:22:17 -0500, Benjamin Smedberg wrote:
> On 1/13/10 12:33 PM, Philip Chee wrote:
>
>> The SeaMonkey project would certainly like to retain our Profile Manager
>> UI. While parts of it are forked, I hope that the backend that it
>> depends on would remain intact.
>
> As noted in the bug, or here, or something, Neil and I discussed the
> possibility of maintaining profile management functionality outside of
> XRE_main, and that should be possible, if you're also willing to maintain
> the restart logic that needs to go with it.

That's good to hear. But wouldn't any restart logic be incompatible with
the proposed XPCOM and other changes you are planning?

> The whole point of this exercize is to remove the backend to the point where
> we can make significant improvements to the startup sequence.

Does this mean that we (SeaMonkey) can have either a profile management
system OR improvements to the startup sequence but not both? For the
record, I'm all in favour of improvements in the startup sequence, after
all there's this Nokia N900 in my Christmas wish list....

> For the record, I'm currently completely absorbed with loretnz and OOPP, and
> so this bug is not something that was meant for imminent checkin, and I
> haven't even seriously discussed it with Mossop, so the imminent angst is
> probably out of place.

Unfortunately the recent contretemps regarding themes/personas and
extensions/jetpacks seems to have made a lot of people unusually paranoid.

Phil

--
Philip Chee <phi...@aleytys.pc.my>, <phili...@gmail.com>
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.

[ ]Just remember: when in doubt, you're always right.
* TagZilla 0.066.6

Boris Zbarsky

unread,
Jan 13, 2010, 1:49:29 PM1/13/10
to
On 1/13/10 1:42 PM, Philip Chee wrote:
> That's good to hear. But wouldn't any restart logic be incompatible with
> the proposed XPCOM and other changes you are planning?

Why? The painful part is preserving the command-line arguments, right?
So the current code flow is start executable A, then A has to quit
itself and restart itself while preserving command-line arguments.

The new setup could be a script or small executable (which is what the
user actually runs) which puts up UI to select a profile, then launches
A _once_ with the right arguments, no?

Unless I'm seriously misunderstanding the situation here...

-Boris

Ragavan Srinivasan

unread,
Jan 13, 2010, 2:34:42 PM1/13/10
to
Jumping in a bit late here after chofmann pointed out this discussion.


On 1/12/10 9:05 PM, chris hofmann 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 think these are both important questions to ask. On the second one, we
should get some data from the recent Test Pilot study we did where we
surveyed users on whether they share a computer. The results should be
out soon.


> 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.

+1.

Ragavan

Mike Beltzner

unread,
Jan 13, 2010, 3:51:15 PM1/13/10
to Ragavan Srinivasan, dev-pl...@lists.mozilla.org
On 2010-01-13, at 2:34 PM, Ragavan Srinivasan wrote:

> I think these are both important questions to ask. On the second one, we should get some data from the recent Test Pilot study we did where we surveyed users on whether they share a computer. The results should be out soon.

That's great to hear, though we should also be sure to (as we have with other Test Pilot studies) understand that the audience there skews a little technical.

>> 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.
>
> +1.

Well, that's the kind of research that gives us the other side of a cost/benefit equation to making changes here. I find this entire discussion to be a little mis-oriented, since at no point has anyone questioned the value of the functionality of the feature. In fact, as bsmedberg pointed out in an earlier email, he first wanted to know if the module owner (Dave Townsend) agreed with his assertion that this change was required for refactoring, and thus requested review. At that time he planned on working to better understand who was using the specific implementation of the functionality (the Profile Manager UI) and how we could support those use cases while gaining the benefits of the code change.

The Test Pilot data will help us understand if there are many users with multiple profiles (though I don't think it will be able to determine if that's intentional, or the result of profile corruption) but even if the answer came back "everybody uses multiple profiles" we may still want to make this change, although we'll likely want to invest more deeply in its eventual replacement.

We absolutely can NOT put ourselves in a position where "how the browser is currently used" is the sole datum used to make decisions about UI or platform changes. That's not the way to lead with design.

cheers,
mike

supernova_00

unread,
Jan 13, 2010, 5:25:10 PM1/13/10
to
FWIW, if the profile manager goes, so do I from the testing world.
I'm not going to take all the extra time that would be needed to
regression test that would be required without a profile manager.
I've spent hours using the profile manager as it is now to test
hundreds of builds going back years for regressions; without a profile
manager I would not have done that. I definitely would not do that
now even if it required to go back and get a week or two worth of
builds if there wasn't a profile manager. If a direct replacement is
not immediately checked in (immediately meaning with one nightly) then
the devs are failing the testing community and are going to screw
themselves out of all the free help they receive from regression
testers that spend valuable time to track down issues.

I also don't understand how if -P isn't used to start the profile
manager then how is the startup time affected? If it is affected by
more then lets says 50ms(to run code to check if the profile manager
should start) then something is wrong and that is where the vast
amount of time to fix this "issue" is where the work needs to be done
instead of trying to build a better mouse trap to fix something that
is not broken.

Like I said, I've been a tester for about seven years in which I feel
that I have been very valuable with nearly 400 bugs filed and
thousands upon thousands of bugs triaged in one way or another,
countless hours on IRC supporting end users and thousands of posts on
Mozillazine and Neowin.net helping users. Mozilla would lose a great
deal of valuable testing experience by not giving me this tool that
allows me to easily do this on my free time.

supernova_00

unread,
Jan 13, 2010, 8:01:15 PM1/13/10
to
Beltzner replied to me and it had moz.dev.planning on the email but
for some reason it didn't post here.

"I don't think that threats like this are necessary. They don't really
add a lot of value to the conversation (as opposed to your tireless
contributions, which often do!) and they are obviously false. If we
were to remove the profile manager but replace it with a much better
tool, would you actually leave our testing world? I don't think so.

This entire thread is premature, in my opinion, and was started with
some assumptions that were not valid. For example, even had the UI
been removed without discussion (which wouldn't have happened) it
would have happened only on trunk nightlies, and such changes can
easily be reverted. As it happens, bsmedberg was first seeking the
module owner's opinion (that's Mossop) and if the approach was
validated, then he would start figuring out what manner of replacement
would be needed and how best to deliver it.

Why don't we all spend less time accusing each other and venting our
spleens, and actually spend time determining what it is that we need
to accomplish and how best to accomplish it. I have attempted to do
this by enumerating use cases and trying to determine which need to be
part of the product, and which may be better served by an ancillary
tool.

We're all part of this community for a reason: to work together to
build the best web browser possible in order to move the web forward.
Nobody's trying to minimize anyone's work or contribution, and while I
understand the emotion that leads to that sort of accusation,
ultimately it's all of our responsibility to keep a level head about
things.

cheers,
mike"

Mike, thank you for the direct reply. I didn't say that as a threat,
I'm just stating that I will no longer regression test without a
profile manager that made regression testing a heck of a lot simpler
then having to manually create and edit shortcuts for each build I
unzipped. No, I would not leave the testing world if a much better
tool was provided. A better tool hasn't been presented or even a
discussion had on a better tool at this point. I'm thinking a lot of
the displeasure here is that a much better tool is not available and a
rough draft of one does not even exist. Ben submitting a patch and
requesting review to "Remove profile manager and named profile
support" after four years of no real discussion in the bug is a shock!

Where was the discussion prior to the patch being submitted and a
review being asked for? This discussion was started a month later.
Where is the much better tool or even a proposal for one? What was
expected to happen during the time the profile manager was missing
from the trunk and if/whenever a replacement is ever made. Even if an
extension existed to provide some of the current functionality I'd be
happy and I think so would most others here but the profile cannot be
removed at any point in the near future without some kind of
replacement without a loss of valuable testers no longer bother to
regression test due to extreme hassle that would be needed to perform
regression testing. Yes I'm only arguing this as a tester but that is
because supposedly there would be some kind of replacement before the
next release which I don't believe because if that patch had been
checked in, we'd currently be left without a profile manager on the
trunk and the soon to be lorentz branch, which means 3.6.* would lose
the profile manager in a dot release.

paradisaeidae

unread,
Jan 14, 2010, 12:21:22 AM1/14/10
to
Functions of the Profile manager could make use of the drag and drop
features now available.
Significant personally usefull information is held in a users profile.
Any step towards a sense of owning this will benefit FF.
A svg representation of a user's profile could assist in backups of
portions of a profile.
Drag bookmarks to desktop, gets a .zip file.
Dragback, re-installs bookmarks.
Good for major rev updates, drag cookies... Auth info...
So when gently migrating up from say, 3.5 to 3.6, having a portable
beta version of 3.6, such data could be moved between versions.
Pathname to default settings could be renamed appropriately....
presently Mozilla/Firefox/Profile/n9v31lia.default ..... indicates
obfuscation of data.
Being that it is in a hidden folder by default does not help. (Win).

paradisaeidae ...pulls head in....

dolphinling

unread,
Jan 14, 2010, 2:16:45 AM1/14/10
to
On 01/13/2010 08:34 AM, Robert Kaiser wrote:
> So, if the startup paths are what is really our greatest concerns, can
> we make firefox.exe/xulrunner.exe/... just have launch the profile
> manager with a commandline option as a lightweight application and
> *completely restart* for launching a profile from within that UI? If we
> can speed up the startup paths that much by not having profile manager
> UI in the middle of the sequence, then this might not even slow down
> launching a profile from that UI much - and still give us the
> possibility of having it, even if we might make it not come up by
> itself, i.e. without a specific option, or something like that.

+1 to this.

Can we assume that since profiles are a rather hidden feature to begin with,
most people who use them are competent enough to create a shortcut with a
command line option tacked on?

If so, it seems like the benefits to this approach are great:
It takes the profile manager out of the normal startup code so all the
refactoring that's needed can be done;
The profile manager can continue being shipped with the product, so there's no
extra barrier for people like an external application would require (since I
doubt an extension could handle this);
It would probably make it easier to solve some problems with the current
version, like have the PM come up when you click on your firefox icon, then if
the selected profile is already running, open a new window, else start a new
instance.

QA should be unaffected (they definitely know how to do this) and helping people
with profile-related problems is just as easy as it ever was.

--
dolphinling
<http://dolphinling.net/>

Phillip Jones

unread,
Jan 14, 2010, 8:36:34 AM1/14/10
to
dolphinling wrote:
> On 01/13/2010 08:34 AM, Robert Kaiser wrote:
>> So, if the startup paths are what is really our greatest concerns, can
>> we make firefox.exe/xulrunner.exe/... just have launch the profile
>> manager with a commandline option as a lightweight application and
>> *completely restart* for launching a profile from within that UI? If we
>> can speed up the startup paths that much by not having profile manager
>> UI in the middle of the sequence, then this might not even slow down
>> launching a profile from that UI much - and still give us the
>> possibility of having it, even if we might make it not come up by
>> itself, i.e. without a specific option, or something like that.
>
> +1 to this.
>
> Can we assume that since profiles are a rather hidden feature to begin with,
> most people who use them are competent enough to create a shortcut with a
> command line option tacked on?

No especially if Your OS (Macintosh) Doesn't use Command Line without
the aid of Terminal (which throws you in FreeBSD UNIX). A task you want
no part of, if you no versed in UNIX. You can wipe clean your main Hard
drive in a Heart beat without you knowing what your doing. Similar to
the old DOS INIT command which would Initialize the very hard drive you
were working from.


>
> If so, it seems like the benefits to this approach are great:
> It takes the profile manager out of the normal startup code so all the
> refactoring that's needed can be done;
> The profile manager can continue being shipped with the product, so there's no
> extra barrier for people like an external application would require (since I
> doubt an extension could handle this);
> It would probably make it easier to solve some problems with the current
> version, like have the PM come up when you click on your firefox icon, then if
> the selected profile is already running, open a new window, else start a new
> instance.
>
> QA should be unaffected (they definitely know how to do this) and helping people
> with profile-related problems is just as easy as it ever was.
>


--

S. Beaulieu

unread,
Jan 14, 2010, 10:17:07 AM1/14/10
to
dolphinling a écrit :

>
> Can we assume that since profiles are a rather hidden feature to begin
> with, most people who use them are competent enough to create a shortcut
> with a command line option tacked on?


Absolutely not.

S.

David E. Ross

unread,
Jan 14, 2010, 11:13:46 AM1/14/10
to
On 1/13/2010 11:16 PM, dolphinling wrote [in part]:
>
> Can we assume that since profiles are a rather hidden feature to begin with,
> most people who use them are competent enough to create a shortcut with a
> command line option tacked on?

That's a bad assumption. Profiles are not hidden. Profile Manager is
readily accessible from the menu bar in SeaMonkey. Release notes for
SeaMonkey 2.0 contained significant information on how to migrate
profiles.

--
David E. Ross
<http://www.rossde.com/>

Go to Mozdev at <http://www.mozdev.org/> for quick access to
extensions for Firefox, Thunderbird, SeaMonkey, and other
Mozilla-related applications. You can access Mozdev much
more quickly than you can Mozilla Add-Ons.

Robert Kaiser

unread,
Jan 14, 2010, 12:21:10 PM1/14/10
to
David E. Ross wrote:
> On 1/13/2010 11:16 PM, dolphinling wrote [in part]:
>>
>> Can we assume that since profiles are a rather hidden feature to begin with,
>> most people who use them are competent enough to create a shortcut with a
>> command line option tacked on?
>
> That's a bad assumption. Profiles are not hidden. Profile Manager is
> readily accessible from the menu bar in SeaMonkey. Release notes for
> SeaMonkey 2.0 contained significant information on how to migrate
> profiles.

This is a very SeaMonkey-specific extension already in SeaMonkey 2.0,
let's care about that after we cleared up where the common platform is
going. As Benjamin has stated, even if the core platform and Firefox
removes this, there are potential solutions for implementing it in a
SeaMonkey-specific way - but I'd rather have this be platform code. Once
we know the exact future of this, let's think about how to do the
in-application part SeaMonkey has.

Robert Kaiser

Philip Chee

unread,
Jan 14, 2010, 1:04:39 PM1/14/10
to

No, It just means I have totally no idea how this works so I'm trying to
understand how it all fits together. Sorry for all these stupid questions.

Jean Couprie

unread,
Jan 14, 2010, 1:43:22 PM1/14/10
to
I am not sure that this discussion goes in the right direction : I
think that we have first to define what the users wish to have, then
ask ourselves if the present architecture fulfill this needs or an
other architecture will give better results and at which cost. Doing
small patches is often a dead-end or gives only small improvements :
an old tyre full of Rustines will never be a good tyre !

I'll start by explaining why I use 3 profiles for my user Windows
account. My children, when they are at home, have each a limited
Windows account and can do what they wish without modifying my
settings. I am the only one with administrator rights. My experience
does not cover the needs of people that use different FF profiles to
share a PC or are testers.
My 3 profiles are : 1 normal surf with strict security options (I
cannot register to AMO because I don't see the anti-bot image to
copy), 2 default options (in case 1 is too strict, here I can see the
anti-bot image) and 3 more lax needed for some applications. I wish
to keep this functionality. In fact my true need is to define several
sets of options (trough Tools tab or about:config) and shift from one
to the other. I need 3 .ini presently this translate to 3 profiles
within directories defined in profiles.ini which is deeply hidden in C:
\Documents and Settings\ of XP ; But this directories contains similar
files : does I need this ? e.g.
- for the bookmarks, do I need to enter 3 times the same in 3
different files ? I think that it is lost time and so longer FF
sessions that seems to be slow. When you use different FF profiles to
share a PC you may have different opinions and wish to have your own
bookmarks.
- for urlclassifier3.sqlite which is the database for dangerous sites,
their sizes ranges from 53 MO to 27 MO that means that some are very
outdated. FF is in a bad situation either it update at full speed
before doing anything else and it is slow to start or it update at low
speed in the background but the user is unprotected during a long
time. The minimal improvement is to have only 1 file per user that
should not raise any problem of right to write. It should be better to
have only 1 file for the whole system, don't cry that it is a
violation to security rules to have several users updating the same
file : this is done by the anti-virus for the signatures database that
every one can update.
-Other files should be reviewed, they can give similar or different
results. In most of the cases, I think that having only one version of
the file is sufficient and will speed up the process.
I think that we should speak of "user data" instead of "profiles" and
that the C:\ is not a good location, if we have the choice, for them
because when there is a big crash that need format and reinstall of
Windows all files in C disappear. Most of the PC presently sold have 2
partitions defined, the installer should allow to put "user data"
somewhere in the second partition that is normally not corrupted or
erased by/after the crash. Also this ease backup.

Now you need 2 interfaces adapted to this new architecture. One to
create, modify or delete the .ini but it is seldom used and does not
need to be very rapid. The other has to choose among the sets of
options at each start, speed is important because it is often run. As
an user I don't accept to write a command with parameters as "firefox -
p profilen", I don't like the short-cut solution that need the Firefox
icon + the name of the profile to make the choice and so cannot be put
in the quick launch bar. I favor a simple front end showing very
rapidly (and that can be used as a splash screen) the list of defined
sets of options and calling "firefox -parameter_list" : if there is
only 1 set, FF start immediately else it wait till I have selected
one. This may avoid that, if FF is slow to show something, I think
that Windows has not detected my first click and that I have to click
a second time...

Are these ideas compatible with the uses of the profiles done by
testers ?
What is the development cost in time ?

Justin Wood (Callek)

unread,
Jan 15, 2010, 2:35:50 PM1/15/10
to
Just as an FYI:

http://whereswalden.com/2010/01/15/more-es5-incompatible-changes-regular-expressions-now-evaluate-to-a-new-object-not-the-same-object-each-time-theyre-encountered/

Suggests profile manager usage as testing.

(And he is syndicated on planetmo)

-
~Justin Wood (Callek)

Mike Beltzner

unread,
Jan 15, 2010, 2:42:01 PM1/15/10
to Justin Wood (Callek), dev-pl...@lists.mozilla.org
On 2010-01-15, at 2:35 PM, Justin Wood (Callek) wrote:

Justin, nobody's ever asserted that it's not used for testing purposes. We've asserted that it's not a great tool for testing purposes, and if that's how it's being used, we can build a better tool. We've also asserted that the user needs for Profile Manager can similarly be replaced.

cheers,
mike

Justin Wood (Callek)

unread,
Jan 15, 2010, 2:45:11 PM1/15/10
to

O, I did not mean to assert this as an argument for keeping it. (My
arguments in full have been more articulately stated elsewhere in this
thread).

My point was more of a muscle-memory affect for even the casual
user/tester. And that it is still, even after this conversation began
en-mass, being recommended as a use. Rather than recommending the
-profile option.

-
~Justin Wood (Callek)

custom.firefox.lady

unread,
Jan 16, 2010, 10:17:48 AM1/16/10
to
Re: Removal of the Profile Manager UI?

Has the case been considered of how Firefox running on Windows will react
when double-clicking an associated file (*.htm, etc.) with multiple profiles
and fx set as the default browser? Will it start with the last used profile
if fx is not already running (as there would be no profile manager to use to
ask)? Being able to set a 'default profile' to use in this case would be
nice.

Christopher Blizzard

unread,
Jan 16, 2010, 8:09:04 PM1/16/10
to Mike Beltzner, mozilla.dev.planning group, dev-pl...@lists.mozilla.org, Henrik Skupin
On 1/12/2010 7:38 PM, Mike Beltzner 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)
>

And web developers, who actually use these tools quite a bit. (And
often run other browsers to have "another session" because they often
don't know about the profile manager!)

--Chris

tanstaafl

unread,
Jan 17, 2010, 8:55:38 AM1/17/10
to
Most of this discussion has focused on testers and normal users
switching between different profiles. A lot of users also use the
profile manager to move profiles, even if they do that rarely.