> 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
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 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
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
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.
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
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
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.
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>
> 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.
(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
> 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
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)
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
> 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
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-----
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/
> * 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
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
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
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
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.)
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.
> 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
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
ACK.
regards
Martin
--
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - http://www.asciiribbon.org/index-de.html
> * 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
> 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
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.
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 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
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.
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.
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.
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
> 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).
> 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
>> 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
> 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
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
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
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
> 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
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.
"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 attemp