Removal of the Profile Manager UI?
Henrik Skupin
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
> 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
>
> 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
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
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
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
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
> 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.
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
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
> 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
> 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
> 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)
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
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.
>
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
> 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
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
> 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
> * 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
> On 1/12/2010 9:14 PM, Ed Hume wrote:
>> great. But like Mike, I wouldn't remove the old UI until a new tool
>> has been debugged and is in use. Repeat - in use. Then the old UI can
>> go.
>
>
> That'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
> 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
> 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.
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
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
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
> 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
> 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.
>
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
> 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
> * 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
> 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
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
> 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
> 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?
>
--
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
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
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
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
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
> 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
> 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
>> 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
> 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
> 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
> 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
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
> 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
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
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
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
> 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
> 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
>
> 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
>
> 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
> 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
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
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)
Suggests profile manager usage as testing.
(And he is syndicated on planetmo)
-
~Justin Wood (Callek)
Mike Beltzner
> 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.
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)
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
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
> 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
switching between different profiles. A lot of users also use the
profile manager to move profiles, even if they do that rarely. The
MozillaZine community for example documents that in
http://kb.mozillazine.org/Moving_your_profile_folder because they
found too many users had problems moving profiles by editing
profiles.ini.
maj...@gmail.com
As I commented in the bug, I think most of the use cases for Profile
Manager are better served by beefing up Safe Mode. If Safe Mode could
run as if it were a totally different profile in the first place, and
then the checkbox dialog were added at quit instead of start we could
start up in a "clean" profile, then use the "disable all add-ons"
checkbox to determine if it were the add-ons or something else in the
profile.
This workflow would work for:
Support
QA/regression testing that requires a clean profile
The cases left over are:
QA that requires an existing profile for testing
Which should be suitably handled (in the interim) by the command lines/
scripts being proposed here.
They could also be handled by a Firefox extension that could handle
the UI and launch new instances of itself via -no-remote. No idea if
this is actually possible, but I know when I'm testing something I
still leave my default profile open in a separate process, so a
solution that's post-startup should work as an interim solution as
well.
-Majken "Lucy" Connor
tanstaafl
>
> Support
> QA/regression testing that requires a clean profile
>
> The cases left over are:
> QA that requires an existing profile for testing
A non-trivial number of Thunderbird users insist (despite advice from
other users to have all of their accounts in one profile) on using
separate profiles for personal and business mail because they are
unwilling to take the chance of accidentally intermingling them
(replying with the wrong address etc.). Some of them switch profiles
using shortcuts, others use the ProfileSwitcher add-on.
http://nic-nac-project.de/~kaosmos/profileswitcher-en.html
VanillaMozilla
doubt--
some time ago I initiated a discussion on the user support forum about
whether we should abandon the PM and use safe mode instead.
Knowledgeable users pointed out that:
* there are numerous cases that are covered by PM but not by Safe
Mode;
* creating a profile for testing is reversible, while Safe Mode is
not.
L. David Baron schrieb:
> * Using -profile <directory> on an empty directory makes Firefox
> create a new profile in that directory.
This is fine, but DANGER is near. The current UI has an option to
delete files, and that has been disastrous for some users who have
used it to delete major portions of their hard drives. Whatever form
the PM takes in the future, can we agree that it will not ever delete
user files?
And if the UI does not disappear very soon, can we please remove that
button from the UI?
Hartmut Figge
>This is fine, but DANGER is near. The current UI has an option to
>delete files, and that has been disastrous for some users who have
>used it to delete major portions of their hard drives. Whatever form
>the PM takes in the future, can we agree that it will not ever delete
>user files?
But removing files is necessary and relying on other methods doing this
would even be more dangerous. *eg*
>And if the UI does not disappear very soon, can we please remove that
>button from the UI?
Seems you would like to increase the danger for users. :-P
Hartmut, exceptionally posting here
VanillaMozilla
> As I commented in the bug, I think most of the use cases for Profile
> Manager are better served by beefing up Safe Mode.
Possibly, if it's done right. But keep in mind that the Safe Mode
dialog is capable of irreversible data loss.
You can't just tell a user to try Safe Mode without adding cautionary
notes. For users with limitations (language barrier, computer
illiteracy, etc.), this may be hazardous and needlessly complex.
VanillaMozilla
> 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?
The PM is a prominent part of troubleshooting on all major Firefox
support sites, including Mozilla's own support.mozilla.com . For
reasons I just mentioned.
Majken mentioned incorporating profile management into the Safe Mode
dialog. That's OK if done right, but there is one huge problem to
work around. ***_The check boxes in Safe Mode can cause data
loss._***
Now imagine how this complicates the problem of helping users. You
have to add warnings. Remember also that many users are impaired,
either by a language barrier, by computer-illiteracy, by eyesight,
etc. This really needs to be improved.
VanillaMozilla
interface. I'm just glad it didn't say "delete my files" in a
language I'm not quite familiar with.
On 19 Jan., 14:48, Hartmut Figge <h.fi...@gmx.de> wrote:
> VanillaMozilla:
> But removing files is necessary and relying on other methods doing this
> would even be more dangerous. *eg*
NO. There have been MANY proposals to safeguard user files so they
don't get deleted. They all get promptly WONTFIXED, with nothing more
than an admonition that users should not use the PM. Meanwhile, those
of us who support users have seen many people lose years of work. We
still occasionally see these cases, in spite of saturating the English-
speaking Internet with warnings. I'll say it again: Mozilla programs
must not delete user files!
> >And if the UI does not disappear very soon, can we please remove that
> >button from the UI?
>
> Seems you would like to increase the danger for users. :-P
No. The problem is the button that indiscriminately deletes files.
If you need to delete profile files, you can put them in the trash can.
Hartmut Figge
>Meanwhile, those of us who support users have seen many people lose
>years of work. We still occasionally see these cases, in spite of
>saturating the English- speaking Internet with warnings. I'll say it
>again: Mozilla programs must not delete user files!
That's plain wrong. The PM knows, which files belong to a profile and is
able to delete only those. A user has to know, where the files are
located and has to chose the right ones.
That's clearly far more more dangerous than letting the PM do it's work.
Regarding support of users, i have done it for many years now and know
quite well about the difficulties of a user to locate profiles. ;)
But i am only answering here to be not discourteous and will retire now.
Hart 'lazy' mut
Jesse Ruderman
https://bugzilla.mozilla.org/show_bug.cgi?id=270705
Uninstalling profile deleted large amount of files not belonging to it
and
https://bugzilla.mozilla.org/show_bug.cgi?id=302087
Inadequate warning before Profile Manager deletes non-Mozilla files
.
While I don't completely understand the controversy, I will note that
https://bugzilla.mozilla.org/show_bug.cgi?id=18927
Profile Manager should trash/recycle data files, not delete
was not wontfixed, and I haven't even seen a bug filed to make sure
users creating profiles out of existing directories understand what
they're doing.
VanillaMozilla
> That's plain wrong. The PM knows, which files belong to a profile and is
> able to delete only those.
No it does not. See bugs 273729 and 535529 for two of many examples.
We're off the subject and must stop, but this was too egregious an
error not to correct.
VanillaMozilla
You're right, some of these bugs were ignored, not WONTFIXed. I don't
understand your suggestion about making users understand what they're
doing. The bug reports I have seen were directed toward making sure
the UI wasn't harmful.
And please note that I'm not trying to ignite an old controversy or
spam this discussion. I just want to point out the possible design
problem with any future interface that might delete user files.
VanillaMozilla
one. ;-) (Trying to get out of the way, because I've probably said
everything I know about the subject.)
Phillip Jones
If you have more than one Profile and you decide to delete that profile
instead of just deleting the reference to Profile and leaving the actual
profile in case you need to move say your Mail Directory It wipes out
the entire profile nothing is saved. If you don't realize what your
doing years of Mail, User names and passwords are gone forever. That why
if I create a Test Profile I name it Test Profile and I only put enough
information n to get it functioning and if messages are downloaded I
move the mail Folder to my normal profile changing the name. Then I open
my regular profile and move any messages from the transferred folder to
the same named folder on my regular profile (inbox2 to inbox) then
delete the transferred folder. Or I just leave the test folder for
future use.
David E. Ross
In SeaMonkey, Profile Manager gives the user the option whether or
not to delete the files for a profile when deleting the profile. If I
create a temporary profile and then delete it, I want SeaMonkey to
delete the profile files. Doing this within Profile Manager is
safer than doing it manually, especially for non-expert users. On the
other hand, if you wish to keep the profile files or to delete them
manually, you merely select the "Don't Delete Files" button on the
confirmation popup.
VanillaMozilla
>...I haven't even seen a bug filed to make sure
> users creating profiles out of existing directories understand what
> they're doing.
Well, there's bug 305551.
Daniel Veditz
> 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 sounds like a recipe for extra profiles due to typos and
mysteriously missing data, which I would presume was the reason it
wasn't made to work before.
Majken
Ok, so if we fix the idea that Safe Mode doesn't delete files, but
puts them in trash/recycle bin then that should take care of the
dataloss concerns w my suggestion. Though I'm not sure I've seen many
people on SUMO complain that they lost things after Safe Mode. We
could get data on that if it helps.
-Majken "Lucy" Connor
Daniel
> On 01/13/2010 07:00 AM, Dao wrote:
>> On 13.01.2010 07:33, Alexander Limi wrote:
>>> 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)
>>
>> You can also modify the target location of the desktop shortcut.
>
> If you can do that, then you can make a new shortcut with the
> slightly-different command-line parameters. This is a possible solution
> for the multi-user use case (each user has their own icon).
If you were going to do that, why not give each user their own computer
profile I think most major OS's can be set up multi-user), so the one
internet profile icon on their desktop starts up their own profile??
I'm thinking this is not your general, home-user, situation, rather
there is only one computer profile and, maybe, MAYBE, there are separate
user internet profiles.
My 2c
Daniel
Daniel
> On Jan 16, 8:09 pm, Christopher Blizzard<blizz...@mozilla.com> wrote:
>> 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
>
> As I commented in the bug, I think most of the use cases for Profile
> Manager are better served by beefing up Safe Mode.
<snip>
>
> -Majken "Lucy" Connor
What is "Safe Mode"?? Is this an OS option or a FF/TB/SM option??
If it's an OS thing, I cannot see it being of much use, as different
OS's (Win/Mac/Linux/??) might require different implementations.
My 2c.
Daniel
Daniel Holbert
> What is "Safe Mode"?? Is this an OS option or a FF/TB/SM option??
It's a Firefox (and I think TB / SM) option.
http://lmgtfy.com/?q=firefox+safe+mode
~Daniel
Phillip Jones
I don't know how it works on PC/UNIX/Linux; but on Mac each separate
account requires the installation of software for each account. (there
are utilities that can run across accounts.) And if they use software
other than FF or another Browser, (Office/Acrobat, etc) requires a
separate installation and the license agreement from most software
companies only all one copy on Desktop computer Laptop and a Backup.
Some only one copy period. Each Account has to have its own installation
such things as Fonts.
Plus It complicates matters in doing repairs.
Daniel
O.K. thanks!!
and the very first response on the google search says:-
Safe Mode
Firefox Safe Mode has no connection to Windows Safe Mode. ... Firefox
should start up with a Firefox Safe Mode dialog. Note: You can also
start Firefox in ...
support.mozilla.com/en-US/kb/Safe+Mode - Cached
Daniel
Matthias Spanier
Am 13.01.2010 02:41 schrieb Cheng Wang:
> 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.
>
> [...]
>
> [Profile manager UI is] 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
ACK.
Me being a FF and TB user, I require a simple and easy-to-use way
choosing one of the FF and TB profiles I created for different purposes.
Please do NOT remove the profile manager UI.
Regards,
Matthias
Matthias Spanier
Am 19.01.2010 19:52 schrieb tanstaafl:
> A non-trivial number of Thunderbird users insist [...] on using
> separate profiles for personal and business mail because they are
> unwilling to take the chance of accidentally intermingling them
> (replying with the wrong address etc.).
Yes indeed, and so do I.
Robert O'Callahan
found some interesting bugs, but I have never (as far as I can recall,
which is pretty far) lost profile data.
Rob
Zack Weinberg
Counterpoint: after switching between (what was at the time 3.5-to-be)
trunk debug builds and 3.0.x official builds obliterated my entire
profile including bookmarks, five times in a row, I stuck a patch
permanently at the bottom of my mq stack which changes application.ini
so that release builds and trunk builds never have anything to do with
each others' profiles.
This has the pleasant side effect that they can be run simultaneously
without having to remember any extra command line arguments.
zw
Alexander Limi
settings directory, so experimental builds never stomp on your day-to-day
setup.
With Weave Sync, this should also be less of an issue — having Minefield
store its config/setup in a separate location from Firefox seems like a
no-brainer to me.
--
Alexander Limi · Firefox User Experience Team · http://limi.net
On Tue, Jan 26, 2010 at 11:29 AM, Zack Weinberg <zwei...@mozilla.com>wrote:
> Robert O'Callahan <rob...@ocallahan.org> wrote:
>
> Counterpoint: after switching between (what was at the time 3.5-to-be)
> trunk debug builds and 3.0.x official builds obliterated my entire
> profile including bookmarks, five times in a row, I stuck a patch
> permanently at the bottom of my mq stack which changes application.ini
> so that release builds and trunk builds never have anything to do with
> each others' profiles.
>
> This has the pleasant side effect that they can be run simultaneously
> without having to remember any extra command line arguments.
>
> zw
> _______________________________________________
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning
>
Zack Weinberg
> FWIW, this is what Opera does by default. Alphas/Betas have a separate
> settings directory, so experimental builds never stomp on your
> day-to-day setup.
My girlfriend is presently employed as a web designer, and has more
than a few times complained at me about the difficulty of running
multiple versions of Firefox simultaneously. Opera's behavior was
suggested as the Right Thing that we should emulate. So there's
another anecdote in favor. :)
> With Weave Sync, this should also be less of an issue — having
> Minefield store its config/setup in a separate location from Firefox
> seems like a no-brainer to me.
Yeah. Passwords and bookmarks are the big thing that I, anyway, want
to share across versions.
zw
Alexander Limi
> On Tue, Jan 26, 2010 at 10:57 PM, Alexander Limi <li...@mozilla.com> wrote:
> > FWIW, this is what Opera does by default. Alphas/Betas have a separate
> > settings directory, so experimental builds never stomp on your day-to-day
> > setup.
> >
> > With Weave Sync, this should also be less of an issue — having Minefield
> > store its config/setup in a separate location from Firefox seems like a
> > no-brainer to me.
>
> Sync tools can be dangerous. If I have two profiles which share a sync
> upstream and one is destroyed and then uploads a sync which destroys
> the upstream, and then i run the second browser, i'm screwed because
> it'll download the delete all as it syncs.
>
Sure, but there are ways to mitigate those situations (backup the profiles
before syncing with an experimental build, etc)
Alexander Limi
Sorry, hit the send button a bit too early:
I think Weave Sync may also have a "you are changing more than n% of your
passwords/bookmarks, are you sure this is what you want to do" kind of
safeguard, but maybe I'm imagining things. If not, it should definitely have
that kind of prevention mechanism.
Phillip Jones
Example I use a FTP program Interarchy. I maintain my website on two
computer by setting a Mirror download. That way only files I changed and
I upload manually can be mirrored back to either computer. That way only
changes I make are changed (synced) on both computers. Auto Mirror
upload will change any file that has the date changed even if it happens
to be an old copy.
In other words its one way. Couldn't something similar work here.
Dao
testers with their day-to-day setup on nightly/alpha/beta channels.
Zack Weinberg
> On 26.01.2010 21:57, Alexander Limi wrote:
> > FWIW, this is what Opera does by default. Alphas/Betas have a
> > separate settings directory, so experimental builds never stomp on
> > your day-to-day setup.
> >
> > With Weave Sync, this should also be less of an issue — having
> > Minefield store its config/setup in a separate location from
> > Firefox seems like a no-brainer to me.
>
> This might be best for Zack when he's developing, but we also need
> testers with their day-to-day setup on nightly/alpha/beta channels.
Wouldn't it be handy for those testers if they could have a baseline
release (3.5.x or so), an alpha or beta of the next release, and a
trunk nightly all running at once? I do this all the time when
investigating regressions.
zw
Henrik Skupin
> 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.
How does that work? Do we have that documented somewhere?
--
Henrik
Dao
Sure, and I think many are doing this when investigating regressions.
But we /still/ need people to do their ordinary browsing in experimental
builds, as there are bugs that you won't see in a clean profile.