Profile Manager is still present in Firebird, and as such it requires a UI review, respecification and update.
14 years ago
I think it needs the ability to be accessed from within Firebird, as many users have been complaining about the effort needed to open it.
For windows XP and linux users, the typical users will presumably use XP login accounts to separate individuals. A bigger end user experience goal might be achieved through mapping gecko versions in the profile manager and warning the user of a potential error causing state -- or can we assume that upgrades will not cause profile incompatibility in the future?
It would be great if you added a menu item or something to get to the Profile Manager. I have more than one profile on my user and the average user would have no idea how to open the Profile Manager on OS X without specific directions.
The firefox 0.8 windows installer adds a shortcut in the [start->programs->mozilla firefox] menu which says profile manager. It starts firefox with the -p switch. However, if you click on it while firefox is running all it does is bring up another firefox window. This isn't very intuitive. Either it should bring up the profile manager, or it should display a message (if necessary in the new firefox window) saying that it can't unless firefox is closed. (Sorry if this doens't belong here, or if this has been changed in 0.8+) (And given how often the first piece of advice given in the support forum is to create a new profile, it seems like access from within firefox would be good.)
Need to turn this off for 1.0.
Comment on attachment 148991 [details] [diff] [review] turn off profile manager UI for firefox Requesting review for the configure.in/autoconf.mk.in changes for the trunk
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040524 Firefox/0.8.0+ zip version. Profile Manager (started from cmd line) at one point shows the button to select profile directory. The button doesn't work. remove button or make functional ?
Uh... How does this affect users who keep there profile at non-standard locations? I for one, don't use the standard %appdata%\phoenix (I'm on 0.8) path. but rather a location on my data drive, D:\. How do you specify via a command line a non-standard profile location like D:\Application Data\Mozilla Profiles\Firefox\? Alot of people like Firefox's profiles for there mobility, such as the growing number of people using firefox+profile on a thumbdrive, etc? how does this affect them? Also, I find it hard to believe most Win32 users *really* want to have to use Command Line switches over a UI to create/manage a profile, particularly since creating a new profile a quite useful debugging method even for end-users when they have a strange problem? It's not that it's a task you do daily, unless you're testing, but it's not a point to be disregarded as "not something end-users ever do" either. It's been pointed out to me that there's no bloat/perf gains here, since the back-end is remaining, and Thunderbird has already made modifications to the profile manager since the Aviary branch opened to improve it's look, what's the point of removing it?
Please bring back the ability to chose the profile folder - it is very important for me as I keep my profile on a mapped network drive so it's accessible no matter which PC I log in to on the university network. This is a blocker for me, without this ability I cannot use firefox here (both firefox and the profile are stored on a network drive - I have no local write access)
I agree, the profile manager is escential when developing extension/themes and testing them. Ben could you inform us on what exactly you have planned or are thinking? That could help us to help you and get this resolved the best way possible for everyone (devs, users, testers, etc.).
Will we still be able to choose another profile using -p in the stock mozilla.org builds? I for one use this...
Due to recent checkins, profile folder location can be chosen via command line. You can still create and use new profiles via command line as well.
Does the removal of the Profile Manager UI tie in with bug 177996, which has to do with the UI appearing as a result of trying to open a second Firefox window external to the program? I'm just curious if this removal and the script changes in 177996 go hand in hand, with the ultimate result being that simply calling Firefox in Linux n times will open n windows or n tabs.
Per comment 5, am re-summarizing. Bug 177996 is for managing profiles via command line.
(In reply to comment #13) > Due to recent checkins, profile folder location can be chosen via command line. > You can still create and use new profiles via command line as well. Sorry for a question that won't help solving this bug, but how ? (WinXP, Linux, Mac OS). I never saw a list of the command line switches allowed. I only know "-P". Unfortunately "firefox -?" or "firefox --help" are not there to help.
(Answering to myself) 1. Create a dummy /path/to/profile/folder/pref.js 2. firefox -CreateProfile "name /path/to/profile/folder" (Adapt the path if it's Windows instead of Linux, or Mac OS) Source : http://kb.mozillazine.org/index.phtml?title=Firefox_:_Tips_:_Profile_without_.slt Note 1 : I still think that "-?" should be implemented anyway. Note 2 : I didn't test the above myself yet.
I've been testing what you found, Jean-Marc, but it does not work. In fact, I've never succeeded on changing the profile dir to anywhere else besides %userprofile%\Application Data\Firefox on Windows. This may be a different bug, but still, I've been trying this since Phoenix 0.5. Here's what I did: 1. Left my old profile (in app data) where it was 2. Followed the instructions in the MozillaZine KB article Result 1: The dummy prefs.js is still there. Result 2: In <path-to-profile> there are now these subfolders: "profile-name\xxxxxxxx.slt" The new profile is not (as the article implied) directly in <path-to-profile>. 3. Start Firefox. Result: new (blank) profile is used. I knew this because no proxy is set in a blank profile, and I can only browse with one. I set the proxy and shut down Firefox. 4. Since it seemed to work, I removed my old profile from %userprofile%\app data. 5. Start Firefox again. Result: Proxy setting was blank again. After checking: A new default (blank) profile is created in %userprofile%\app data!! 6. Shut FF and launch with -P: only the default profile is there, not the custom made profile from step 2. Somehow, there needs to be a profile in app data, whether it is used or not. If it is not there, a new profile will be created there, and used by default. If anyone can give me a working way to move the entire profile somewhere else than %userprofile%\application data\firefox\profile-name\xxxxxxxx.slt, I would love to hear it. I want to get rid of the app data\firefox dir. The most user-friendly way would be a (working) profile manager ui, else a working command line. If it is decided that profiles will always be in app data, remove the profile manager completely, including any commandline options related to that.
Thank you Anthon. In my comment #16 I actually hit the long-standing (2000-02-05 !!!) bug http://bugzilla.mozilla.org/show_bug.cgi?id=26761 (Win32). The workaround in short : "firefox -h > %TEMP%\help.txt" Another Mozilla reference (for plain Mozilla but still valid for Firefox) : http://www.mozilla.org/docs/command-line-args.html (This was my last non-bug-solving post. I just hope that this will save time to other testers, like Anthon did.)
13 years ago
Is there a clear way to deal with bugs like bug 212512, bug 122698, and bug 135137 in the absence of a profile manager? This issues arise in the case of deployments on large networks, with profiles stored on network drives.
13 years ago
-minus for preview release, and maybe for final. think we could get by with out work on this since there is a lot to do.
Are there any single-user OSs on which Windows runs? I don't know of any, Linux/Unix has been multi-user since the beginning. Windows has been multi user since 9x or even before if you include Windows for Workgroups. I'm not sure about Mac but since it is now based on Unix, I'm sure it is also multi-user capable. User management belongs in the realm of the OS at this point.
What is happening with this? Profile Manager is still accessible from the command line, but not from the Firefox menu/Start Menu (on windows). I created a bug about the lack of it on the Start Menu (bug 263840) but it's apparently not going to be added. Is it going to be on a Firefox menu?
I realise this has been said already, but I'm going to go ahead and spam this bug anyway... In the space of a couple of hours on IRC and in the Firefox forums, there have been 3 people that have "lost" their profiles due to a crash leaving their profile being locked, and Firefox creating a new profile automatically. Currently the advice for them to switch back to original profile is quite simple. Removing this UI altogether will break that. If profile manager is removed, then Firefox should not create or switch profiles without the user explicitly telling it to do so, even if it finds that an existing profile that is broken.
(In reply to comment #22) > Are there any single-user OSs on which Windows runs? I don't know of any, > Linux/Unix has been multi-user since the beginning. Windows has been multi user > since 9x or even before if you include Windows for Workgroups. I'm not sure > about Mac but since it is now based on Unix, I'm sure it is also multi-user > capable. User management belongs in the realm of the OS at this point. When I bring my laptop in to worrk, I switch to a profile that has proxy servers specified. When my laptop is at home, I do not need proxy settings. For me and others like me, this is anything but a user management issue.
You're using a whole profile just for proxy settings? I just go to the options panel and change the radio button. Or a simple extension could do that toggle.
Created attachment 182091 [details] Wrapper for firefox.exe that terminates old firefox.exe processes that did not cleanly shut down.c I wrote a small Win32 replacement for firefox.exe that calls the original firefox.exe (renamed to firefox1.exe) after ensuring that all running firefox1.exe processes have at least one visible window. Any firefox1.exe processes that have no visible windows are forcibly terminated. We, like many people out there, occasionally have users who "lose" their bookmarks and start page due to something causing Firefox to uncleanly shut down and thus keep the profile locked. I'm not going to tell our end-users to go into the Task Manager to end the process (think "Auntie Mabel" or "Grandma" type of users), so I wrote a small tool that does that for them. I'm hoping that perhaps a part of this can go into the real firefox.exe so that it can kill any previous instances that have no windows open and thus prevent the Profile Manager from appearing (at least, that's one idea). I understand that fixing the root cause of freezing problems rather than working around them is the best approach, but this workaround can handle cases of rogue plug-ins that I suspect are causing Firefox to hang rather than Firefox itself. BTW, thanks for an excellent web browser! The IT Department of a non-profit that I am in, with my help, rolled out Firefox to all of our 100 or so computers as a part of our Windows XP migration. I'll send more details to the appropriate place if I find out what caused one particular user's Firefox to "lose" his bookmarks on two occasions. For now, I've just manually edited profiles.ini to switch his default back to his original to "restore" his bookmarks and make him happy, though I'm hoping that this workaround will prevent this from happening on our agency's computers.
Comment on attachment 182091 [details] Wrapper for firefox.exe that terminates old firefox.exe processes that did not cleanly shut down.c My bad; I'll repost the updated version to the correct bug. Sorry about that..
Why not remove all code for multiple profiles (profiles at all) all together? Every modern operating system has multiple users, which is what people should be using. I, like many people, can no longer count on both of my hands the number of times that either I or one of my friends have "lost" all their settings because their profile was locked. The correct solution for people who wish to store their profiles in a non-standard location should be really be a single preference *with* a UI to change it at any time (would automatically move all your settings to new location). Could someone please mark the blocking-aviary1.1 flag so we as users can get an idea of this bug's prority? Thanks.
Nominating for 1.8b5, users are seeing dataloss by using the UI to delete profiles http://forums.mozillazine.org/viewtopic.php?t=322986
Wouldnt fixing Bug 302087 be better instead of removing this feature?
(In reply to comment #30) > Why not remove all code for multiple profiles (profiles at all) all together? Please, please do this. At least, can we have a command-line switch for "firefox --prevent-accidental-multiple-profiles". I've also had to de-mangle this on several occasions. If the user's profile is somehow locked, I think the solution is either: 1) use mozilla-firefox -remote (open in existing firefox process) 2) killall -9 mozilla-firefox (kill the process that has the lock, then rm path/to/profile/Lock break the lock) 3) exit 1 (exit with failure.) It is extremely unlikely that the user actually wants a new profile - and merging the resulting mess back into a single profile is a difficult job! [It is even worse for mail or mozilla-suite]. Konqueror has neither salting, nor multiple profiles, and I think it is better for that.
"Please, please do this. At least, can we have a command-line switch for "firefox --prevent-accidental-multiple-profiles". I've also had to de-mangle this on several occasions." The fix for bug 253950 has pretty much resolved that issue. The profile manager UI won't appear because of a locked profile now - the user has to specifically use a command line switch in order to mess things up, which is unlikely.
Profiles going away would be a significant loss of functionality for me. At work for example I have a 'dev' profile with extensions for web development installed and nothing else, and a 'default' profile with Adblock and Greasemonkey and all kinds of fun that I want to keep away from real work. Having to set MOZ_NO_REMOTE just to use a different profile has already made using profiles harder, now instead of an official wrapper I have to have my own to set MOZ_NO_REMOTE only in the right cases. Using additional OS accounts is painful and not even possible for all users.
I'm seeing two main issues here. - Profiles should be closer related to user accounts - Some users want to specify an arbitrary location for their profile So how about meeting them in the middle? Here's my proposal. - Remove the profile manager GUI altogether - Keep firefox -p $profilepath around - If no profile path was specified, use the one in the default location, i.e. %APPDATA%\Mozilla\Firefox, ~/.mozilla/firefox/, ... - If a profile was specified, (check if it exists and) use it, and inform the user, e.g. through a dialog box, in the title bar, ... - In both cases, if the profile is in use, inform the user, tell him how to fix it, and exit Firefox This way, profiles become more of an "advanced" feature, which removes a layer for novice users, while maintaining all of the profile switching functionality for expert users. The only caveat I see is that, on single-user OSes, users would have to specify the profile path on every occasion. However, is there any that Firefox still supports, and/or which still has a significant user base? As always, just my two cents. Sorry if I'm being redundant.
Let people get knowledge of profile management gradually. At least to be able to easily decide which folders to back up. More soon.... Markt
Woah, didn't even know people wanted to get rid of this functionality. This is not useful just for multiusers, it's very useful to a single user. I have a profile for Webmail and Banking (separate so there is no risk of session hijack), a profile for normal browsing (which I configure to accept cookies only from certain sites, etc.), one for one-time use browsing (where history gets deleted after browser is closed), one for testing bugs which has no add-ons or themes, etc. This is very useful functionality, please don't get rid of it.
What is very important is to prevent the return of the old Mozilla-suite bug where if a profile was somehow locked, the application would pop up a "this profile is in use, do you want to create another one?" dialog. The result is that non-expert users ended up with multiple unwanted profiles, and a horrid job of merging them together again (this was really nasty with mail). In virtually all cases, the right behaviour was to delete the lock file, but even a complete refusal to start (resulting in a call to tech support before it got too late) would have been better than auto-generating another profile. That's why so many long-time Mozilla-users really really hated the multiple profile "feature"! I can see it's useful, just as long as it can never occur accidentally! BTW, if we're doing this, can we also get rid of the salting of names in the profile directory. (the silly subdirectories named 'ov54jtis.default' etc. It really doesn't provide any useful security improvement, and it's ugly.
Created attachment 416998 [details] [diff] [review] Remove profile manager and named profile support, rev. 1 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.
Created attachment 419607 [details] Pseudocode for suggested profile folder handling I'm all for creating a new profile system, if it has feature parody of the current one (create, select, and delete). However, until that happens, at the very least I'd like to see feature parody on the command line. Just having -profile does not do that. I also don't see how handling this at the command line would prevent re-factoring the code as you mentioned. Yes, it adds code, but the cood its self is not complex. And if I'm reading your patch correctly, a lot of the functionality is already there. It's just missing code to handle the profiles.ini. For example: -profile <path> Remains unchanged. Possibly create the dir if it doesn't already exist. -p <name> [--delete] [--new [<path>]] [--default] IMO this could be handled almost entirely in FindDefaultUserProfile (maybe rename to GetUserProfileDir). If <name> exists, select it. If --delete is specified, delete it than exit. If --new and <name> doesn't exist, create the profile (optionally at <path>). And if --default exists, mark it as default. At the very least, is there a reason why the "-p <profile>" option is being removed? I wouldn't think that would add very much complexity to the FindDefaultUserProfile function. Removing it would cause a lot of problems for people who currently do use multiple profile folders.
Voting against removing Profile Manager UI. And please create a new bug report. This is way old.
So, I'm all for reinventing the profile system, but I don't think it's really feasible to just completely remove the current profile system without having a replacement ready. I use multiple profiles on a daily basis for testing and other development work, and I have Minefield set to ask me at every start-up which profile I want to use. Not being able to use separate profiles would be a huge problem for me. I also know that most everybody in QA uses multiple profiles for testing, too, so unless you want them not to be able to test 1.9.3, some type of replacement needs to be available before this code is removed.
(In reply to comment #43) > So, I'm all for reinventing the profile system, but I don't think it's really > feasible to just completely remove the current profile system without having a > replacement ready. I use multiple profiles on a daily basis for testing and > other development work, and I have Minefield set to ask me at every start-up > which profile I want to use. Not being able to use separate profiles would be a > huge problem for me. > > I also know that most everybody in QA uses multiple profiles for testing, too, > so unless you want them not to be able to test 1.9.3, some type of replacement > needs to be available before this code is removed. You are exaggerating the situation. You can still use profiles, but it requires you to specify the profile location with --profile
and yes, I see that --profile <dir> will still be available, but that's a huge killer for productivity, as I'd have to keep a list of my salted profile directories easily available and accessible, or either rename them to be something more rememberable, which defeats the purpose of salted profiles.
-profile isn't the same anyway, because it puts everything in the same folder, whereas the create profile wizard separates the local and roaming data.
The profile manager is pretty much fine. It's the User-Access which is not. All that's required is an extension for those who are interested in it's flexibility. MarkT チェックアウトが、Jingle だ! It's a Jingle Out There!
Here's my opinion on profile situation wrt support: The current UI really isn't that user friendly as we have to make sure people understand how to exit Firefox properly etc, and if someone comes back for more help we have to go through the process of handling multiple profiles. However it's still necessary to be able to get an answer to "is the problem caused by something in the profile" and it needs to be something users can manage. There should be a switch, I'd put it in the help menu, that acts like safe mode (beef up safe mode?) but lets you run Firefox in a clean profile and ideally doesn't leave the profile on disk after you're done. User friendly and doesn't risk data loss for problem determination.
Additionally, an extension reached via the help menu could 'register' portable profiles. Firefox Portable must be popular enough to warrant a mention in profiles. This could be the missing link in (significant) version upgrade paths. Such an extension could monitor the availability of extensions for the new FF version. The extension could make use of the svg graphics engine to show status of these. It could also show a graphic representation of data stored in off-line DB's. Giving the user a more better handle on increasingly important config-data. HNY! MarkT
QA and others use profiles all the time. Until a replacement is fully implemented, I can't see removing the code.
As noted in this bug, -profile still exists and has all the functionality you need, I think. If not, please be specific about what it doesn't provide.
It doesn't provide a UI that users will use. Why are we taking this out now? Who made this decision and when?
There are two points: * remove UI which confuses users and generates bugs: the creation and removal of profiles, and the interaction with the remoting system leaves users in profiles they don't expect, or deleting directories they don't expect, and other conditions * simplify the startup sequence to remove process startup. For 1.9.3 I would like to try and remove all sources of restarting (profile manager, EM re-registration, version bumps). The profile manager is just one part of this task. I'm made the decision, and I'm hoping Mossop will confirm it.
If we ship a SeaMonkey release without a profile manager, a number of our users will try to kill us. As we can't afford to fork the Mozilla platform, we probably will need to swallow whatever bitter pills you guys hand us, but can we request to have someone of your team tend to those poisonous emails and newsgroup posts we'll get for this?
I discussed with Neil the possibility of SeaMonkey implementing its own profile manager UI, and this should be doable: you would have to implement it "outside" of XRE_main, and perhaps add a little support for passing explicit profile paths into XRE_main, but it's doable if you want to manage the restarts.
Maybe we should discuss this on dev.planning. Mr. Smedberg told me today that's where these kinds of discussions go.
Removing such a wide-spread used (advanced) feature is just insane, especially given the pretext of "adding something better later" (which won't happen anyway). Only those users could be confused who actively *chose* to be confused, since they need to have called the profile manager from the commandline(!) in the first place (or using SeaMonkey). Trying to cure diseases by killing everyone who's infected isn't exactly a good doctor's recipe...
Please use the public discussion which happen here: http://groups.google.de/group/mozilla.dev.planning/browse_thread/thread/06900b8b97c2655d#
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 pesron 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 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 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 create 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.
I have 3 profiles : 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. If you remove Profile Manager UI, how can I define several sets of options and shift from one to the other ?
Please stop adding more comments to that bug. As you can see in the given newsgroup post we are working out possible solutions. Please stay tuned. Thanks.
You don't want to know from users they want an Item developers are so anxious to kill.
Can a Bug vote be against or just for? IF I can vote againt. I will
(In reply to comment #63) > Can a Bug vote be against or just for? IF I can vote againt. I will Please stop spamming the bug with useless comments and questions. Bugzilla has FAQs you can read to explain what each thing is (for the record you are voting for whatever the bug summary is. In this case you'd be voting for the removal). The discussion for this bug is at http://groups.google.co.uk/group/mozilla.dev.planning/browse_thread/thread/06900b8b97c2655d# NOT in this bug report. No reply is needed to apologize or to ask any other questions.
This has evolved into an RFE and not a discrepancy. Even the Summary appears to be asking for a change in design instead of a fix for a discrepancy. Changing Importance from "Normal" to "Enhancement". Should not the Product and Component be "Toolkit" and "Startup and Profile System"?
Any status on this bug? When will the ProfileManager UI be removed? The application specced in bug 539524 is almost at a beta stage. Are there any other blockers?
(In reply to comment #53) > For 1.9.3 I would like to try and remove all sources of restarting > (profile manager, EM re-registration, version bumps). The EM re-registration was solved by splitting startup into two parts, one of global chrome and components (including EM) and one of profile chrome and components. Could not the profile manager be interposed between the two?
No: the problem here is not simply *registration*, but *access*: we need to read and act on preferences pretty early in startup, and fixing that ordering problem is huge. There is also the fact that for performance reasons we keep all kinds of cache data in the profile fastload (now startupcache) files.
Under Windows, there is a missing library MSVCR100.dll. See also bug 569268.
This bug report / thread is a bug. It is a Barf-bug. A MSoft-Troll-bug. Whoever / whatever advocates the removal of access to user oriented data is dangerous to the mission and mandates of Mozilla. Even the deletion of one's own data should be an option. With safety cover over the button.. http://www.radioshack.com/product/index.jsp?productId=2062493 User preferences should be at a visibility equal to menu-bar visibility. The user data is the user-equity of the Mozilla experience. How can people continue to love it when they do not know where it is or have control of it? MarkT
Mark you do know your post is out of line and may get your account closed especially for the advertising in your link. Although users would prefer having the Profile Manger as it is. The developers have they decided they know better what the users want and need than the users do. Just be resigned to using what the developers wish to give us.
WTH? You can't remove a useable feature - Firefox 4 has removed a lot of useable features yet (like statusbar and the helpful addons dialog to replace it with silly, unuseable garbage). Do you want to get back times with Firefox and 5 % spreading?
(In reply to comment #72) > WTH? You can't remove a useable feature - Firefox 4 has removed a lot of > useable features yet (like statusbar and the helpful addons dialog to replace > it with silly, unuseable garbage). Do you want to get back times with Firefox > and 5 % spreading? The profile manager is alive and well, it's just been detached from the installation based on how little it's used. Not exactly a huge issue, especially given that there are performance gains. It will also not be removed until after Firefox 4.0. You can find further information and a download of the new profile manager here: http://jagriffin.wordpress.com/2011/01/11/profilemanager-1-0_beta1/
Many thanks to Paul [sabret00the]Comment 73 2011-01-20 09:30:46 PST for his clarification ! With this before comment 10 the length of this bug report would have been divided by 3 or 4 ! And also the lost time ! A missing clarification : when I start Firefox directly (without going through the new profile manager) what do I obtain ? Default profile ? This seems obvious but should be stated... I don't like to be forced to go to the huge (for same reason see §2) thread : http://groups.google.co.uk/group/mozilla.dev.planning/browse_thread/thread/06900b8b97c2655d#
Just to be clear, are we talking about only removing _access_ to the profile manager UI (via cmd line or otherwise) or about removing all related code (like the nsIToolkitProfileService component) from the codebase? The FEBE extension currently uses the nsIToolkitProfileService component extensively to create/restore backed up profiles. If this is removed, the extension will lose much of its functionality.
(In reply to comment #74) > Many thanks to Paul [sabret00the]Comment 73 2011-01-20 09:30:46 PST for his > clarification ! > With this before comment 10 the length of this bug report would have been > divided by 3 or 4 ! And also the lost time ! > A missing clarification : when I start Firefox directly (without going through > the new profile manager) what do I obtain ? Default profile ? This seems > obvious but should be stated... > I don't like to be forced to go to the huge (for same reason see §2) thread : > http://groups.google.co.uk/group/mozilla.dev.planning/browse_thread/thread/06900b8b97c2655d# No problem, glad I could help. And yes, if you don't select a profile through the profile manager and instead load Firefox/Minefield directly, it will load whichever profile is set as the default. Of course you can change the default profile by using the profile manager.
(In reply to comment #75) > Just to be clear, are we talking about only removing _access_ to the profile > manager UI (via cmd line or otherwise) or about removing all related code (like > the nsIToolkitProfileService component) from the codebase? > > The FEBE extension currently uses the nsIToolkitProfileService component > extensively to create/restore backed up profiles. If this is removed, the > extension will lose much of its functionality. Having had a quick butchers at the patch, nsIToolkitProfileService is removed completely. I could be wrong however. Perhaps this would be a good opportunity for the author of the extension you mention to recreate the service in his own flavour in order to sustain the functionality that you'll miss.
The Profile manager described in http://jagriffin.wordpress.com/2011/01/11/profilemanager-1-0_beta1/ also includes "create/restore backed up profiles" functionality. Which is better ? it or FEBE extension ? Do we need both ? We have to check.
Will it still be possible to call a specific installation with at specific profile via a short cut or command line? Will "Path\to\installation" -P Profilename or "Path\to\installation" -profile path\to\profile still work?
Yes, you can still select an existing profile. It's only the UI that will be removed.
Will nsIToolkitProfileService be removed from the codebase? In comment #77, Paul indicated that he thought it would be, but was not sure. Can someone answer this definitively?
If you had spent the 5 minutes to read the patch, you would see quite definitively that it does.
Is it still the plan to remove this for Firefox 5?
(In reply to comment #83) > Is it still the plan to remove this for Firefox 5? I've asked Benjamin to produce an updated patch, as soon as that is reviewed we'll land it on mozilla-central. It'll go in whatever is the next release of that code.
Please let :jgriffin or myself know if there is any work needed (code/documentation/etc) that needs to be done for the standalone profilemanager (bug 539524) that is blocking for this bug.
Comment on attachment 416998 [details] [diff] [review] Remove profile manager and named profile support, rev. 1 Needs an updated patch
Has this plan been abandoned?
No, merely postponed for more important work.
Why do we want to remove this anyway? What's the problem?
They want to save five minutes of Code writing. And some claim That it can cause problems for new users, creating new profiles unintentionally. There is no rational reason to remove it. I've used FF and SM and it predecessors and as long as Profile manager has been in existence. I have never accidentally created a Profile, nor has it on its on. I think it boils down to a piece a code that developers don't want to be bother with.
Please, bugzilla is not a chat forum. Please don't clog up the bug with chatter.
The actual reason, afaik, that this is being removed is a significant hit on startup time, which is one of the chief demands of users. There is also a standalone ProfileManager application, which not only does everything the in-built profilemanager does, but much more. :jgriffin, do you have a link? Are there any statistics on startup time? These should probably be posted here.
(In reply to Jeff Hammel [:jhammel] from comment #92) > The actual reason, afaik, that this is being removed is a significant hit on > startup time, which is one of the chief demands of users. There is also a > standalone ProfileManager application, which not only does everything the > in-built profilemanager does, but much more. :jgriffin, do you have a link? The standalone ProfileManager app is available at http://ftp.mozilla.org/pub/mozilla.org/utilities/profilemanager/1.0/
Startup time is *not* a reason for this change. The code complexity of named profiles and their poor interaction with OS integration and remoting features is the primary reason for this change. In any case, this bug is not for discussion of the feature in general, please take that to mozilla.dev.apps.firefox.
Maybe landing this could help with bug 709193.
Well, although I also don't see the need to remove the profile manager UI, there is the ProfileSwitcher add-on as well if we need different profiles for work, personal, test, troubleshooting, etc.
(In reply to Juan M. Gonzalez from comment #96) > Well, although I also don't see the need to remove the profile manager UI, > there is the ProfileSwitcher add-on as well if we need different profiles > for work, personal, test, troubleshooting, etc. There is also the standalone profilemanager application, as mentioned in comment 93 : ftp://ftp.mozilla.org/pub/utilities/profilemanager/
I am not working on this currently.
Although this seems bonkers to me (I'm a heavy user of separate profiles so that I can have different configurations for different jobs or different sync accounts), aren't we ignoring the fact that another browser added profiles in late 2011? I think with a bit of work on the UI (being able to switch profiles from within the main menu or a toolbar button), this would actually get a lot of traction. A separate application doesn't really cut it - if I just want to switch to work configuration from home, I don't want to leave Firefox to do so - and in fact there are plenty of other tools that allow multiple profiles in the same application with an easy switch between them. Not all profiles are related to multi-user scenarios or developers.
I too think it Bonkers to remove. I feel like Its developers runing out of stuff to think up and just removing something Valuable just because they can do it.
(In reply to Phillip M. Jones, C.E.T. from comment #100) > I too think it Bonkers to remove. I feel like Its developers runing out of > stuff to think up and just removing something Valuable just because they can > do it. A bug is not an email list or a web forum. Unless you're contributing to the technical state of this bug, please don't post comments here.
Rather than remove it, make it easier for those of us with multiple sync'd profiles (home, work, development etc) to launch them. See Google Chrome.
What am I supposed to do if say I want to create a new Profile to test That new Google Chrome version of FireFox (Austrialias) I hate Chrome worth a passion. But I don't want to screw up my current version now. I already have an Aurora Profile setup. If there is no Profile manger once switch to Austrialias I don't wantto screw upmy regular profile forever.
(In reply to Phillip M. Jones, C.E.T. from comment #103) > What am I supposed to do if say I want to create a new Profile to test That > new Google Chrome version of FireFox (Austrialias) I hate Chrome worth a > passion. But I don't want to screw up my current version now. I already have > an Aurora Profile setup. If there is no Profile manger once switch to > Austrialias I don't wantto screw upmy regular profile forever. This is not intended as a discussion forum but note that All current Firefox versions including the Nightly UX have the built-in profile manager still. (The standard Nightly is now also Australis) There is a standalone profile manager available see https://developer.mozilla.org/en-US/docs/Profile_Manager General Firefox Support questions may be asked on https://support.mozilla.org Advanced & technical Support questions are better addressed to a suitable external forum such as http://forums.mozillazine.org/index.php You may also be interested in the mailing lists etc. http://www.mozilla.org/about/forums/#general-development
Keep it and improve it! Multiple profiles for things like jobs, news, hobbies, technology, school, shopping, etc are a top feature.
Use case for multiple profiles: I generally browse with preferences set to allow cookies and images only from the domain I have requested and popups disabled, along with some other settings. I also have an extension installed that inhibits tracking much better than the often-ignored Do-Not-Track flag; that extension makes each request for a Web page send different headers to the extent that it appears I am jumping from one country to another. However, when I do banking or manage my investments via the Web, the financial institutions with which I have accounts required that I allow all cookies and images and that I enable popups. Those sites also get very confused by my tracking-inhibiting extension. Yes, I could whitelist those sites for cookies, images, and the tracking-inhibiting extension; but I never know what third-party domains also need to be whitelisted. Thus, I have a separate profile for money management with the preferences set accordingly and the tracking-inhibiting extension not installed.
(In reply to David E. Ross from comment #106) > Use case for multiple profiles: > > I generally browse with preferences set to allow cookies and images only > from the domain I have requested and popups disabled, along with some other > settings. I also have an extension installed that inhibits tracking much > better than the often-ignored Do-Not-Track flag; that extension makes each > request for a Web page send different headers to the extent that it appears > I am jumping from one country to another. > > However, when I do banking or manage my investments via the Web, the > financial institutions with which I have accounts required that I allow all > cookies and images and that I enable popups. Those sites also get very > confused by my tracking-inhibiting extension. Yes, I could whitelist those > sites for cookies, images, and the tracking-inhibiting extension; but I > never know what third-party domains also need to be whitelisted. Thus, I > have a separate profile for money management with the preferences set > accordingly and the tracking-inhibiting extension not installed. That's great. However, for the billionth time, stop listing usecases for profiles. Notice the "UI" part of this bug title. All that is being discussed is the interface for the profiles system, not the profiles system itself. You can use the dedicated profile manager instead. : https://developer.mozilla.org/en-US/docs/Profile_Manager
To avoid useless discussions (during for more than 10 years) can some one with strong authority in development state that : 1) the need for several profiles and a way (e.g. UI) to switch from one to another is agreed/recognized. (no more use cases needed) 2) there are presently 2 ways to choose the profile at start up of Firefox : a) the old way integrated in FF, b) an external program by Griffin that has been ruined (false error message) by the resolution of an other bug and is no more supported/updated, 3) that the solutions are : -keep a), improve it and suppress b), -improve b) and suppress a), -create something new and after its successful implementation suppress a) and b). 4)Give to users an approximate time frame e.g. 6 months, 1 year, several years...
> b) an external program by Griffin that has been ruined (false error message) by the resolution of an > other bug and is no more supported/updated, I'd love to find a community owner for this; if anyone is interested, please contact me.
https://addons.mozilla.org/en-US/firefox/addon/profilist/ has great UX for Profiles. Also, compared to the upcoming Containers system, it's much cleaner, safer, and clearer as to it's purpose and trustworthiness (separate, customizable space per-identity vs. tab + a color ribbon and forced "topic" name). I found this antique bug report from the wiki on Containers which cited that Profiles were "too much work for people." It's not, if the UX is improved. It will only get worse if you remove what little (hidden) UX there is now. Please don't.
Brief Update (In reply to John Hesling [:John99] from comment #104) > ... > All current Firefox versions including the Nightly UX have the built-in > profile manager still. (The standard Nightly is now also Australis) > There is a standalone profile manager available see > https://developer.mozilla.org/en-US/docs/Profile_Manager > ... The standalone profile manager may well now be broken and unsupported. Progress may be made on replacing the profile manager. Firefox Release now has about:profiles See for example Bug 1232629 I do hope the new about:profiles is documented, and if the existing profile manager is deprecated other than seammlessly being replaced by about:profiles that the deprecation and alternative is well documented in advance.