With eventual removal of profile management, we will need a mechanism to replace this behavior for testing and triage and support teams. This application could also be a shim while in-product support for a replacement UI is created.
There has been much discussion on dev.planning and dev.platform. Pulling together some possible requirements from those threads we have:
= Standard Behaviors =
- 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
= Test/Triage/Support Specific Behaviors =
- 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
- Restoring a backed-up profile (just want to be explicit)
- Merge two profiles together.
- ability to tie a specific profile to an application version
= A Triage/Support Specific Workflow =
* Start in a new clean profile
* In the new, clean profile, have a way to click a button to get back to "normal" mode.
Feel free to add more suggested requirements for such a tool below. Also, if you're interested in helping work on it, we're looking for volunteers.
Clint, shouldn't it block bug 214675 instead of depending on bug 278860.
* renaming profile
* ability to provide custom location of profile dir
fwiw, this bug should block bug 214675 so that nobody should checkin a patch to remove the current UI without a new tool being available yet (what - of course - has to have parity with current UI feature-wise).
We already have a couple of items in the list. For the beginning I feel that the core features the current UI provides us should be implemented so we can continue our work in a way we are used to.
Some question I have in general:
* Do we talk about an extension, component, shell script or what else?
* How can it be integrated into Firefox, Thunderbird and others?
* Can it replace the profile manager ui as what we have today?
This is an RFE, not a discrepancy. Changing Importance.
Why is this only for test and triage and not for end-users?
@Henrik, I typed the wrong bug in here for the dependency, removing that.
@David: Anyone can of course use this tool, but I am not going to try to create an end-user tool. Let me try to elucidate the difference and the reason why. The testing/triage/support community need far more features and control over profiles than normal end-users generally do. The testing/triage/support communities can live with technical jargon and will also understand the implications of what they are doing, so this tool doesn't have to look good, doesn't have to integrate seamlessly into the application it is running with and doesn't have to minimize its complexity overly much.
Whereas, if the tool were a true "end user" solution, I would spend an enormous amount of effort crafting something that was seamlessly integrated into the application, didn't overwhelm the user with complexity and just did the common set of things (create, delete, use, move profiles for instance) very well with minimal disruption.
Frankly, we have much more qualified people in the Mozilla community to attack the problem for end users who will do a better job than I can. I do hope that the code we write and the back-end lessons we learn by writing this tool will help those people to craft the perfect end-user tool, but that is not my aim to start out with. My aim in the beginning is to craft something we can use for testing/triage/support and then from there, the folks who work on the Mozilla User Interfaces can take and use that code to generate the correct end-user tool. I'll of course work with those folks, but as I said above, I think the more expedient and easier thing to do is to start by solving the problem for the testing/triage/support constituencies before attempting a true end user solution.
I would actually love to have this as part of a suite of web developer tools - it's really useful for testing + development to have separate profiles for both extensions and for logins + supporting different Fx versions with one profile.
I request that the implementation provide a basis for implementing the user interface requested in bug #540194. While that might require more effort, it would avoid the greater combined effort needed to implement two Profile Managers (one for test and triage and one for users).
(In reply to comment #3)
> We already have a couple of items in the list. For the beginning I feel that
> the core features the current UI provides us should be implemented so we can
> continue our work in a way we are used to.
> Some question I have in general:
> * Do we talk about an extension, component, shell script or what else?
To the best of my understanding, this will be a standalone xul application that lives in mozilla-central. I'm not sure where it should live...ideas would be appreciated. Is there are any other opinions on the form of this solution? It should probably live in mozilla-central since it will probably depend on existing components and other infrastructure that lives there.
> * How can it be integrated into Firefox, Thunderbird and others?
I suppose it depends on what "integrated" means. I think this is an outstanding question and I would appreciate ideas. My inclination is, initially, what integration there is should be in the form of the profile manager using existing code from mozilla-central. What I would like going forward is something that may be packaged as a standalone application or be used by e.g. Firefox. However, this would require quite a bit of restructuring on Firefox's part. So I'm mostly inclined to avoid integration now and do this after (partial) decoupling when it can be better assessed what the problem-space is.
> * Can it replace the profile manager ui as what we have today?
I hope so! At least, I think it will have a superset of the functionality. There are some questions re integration and where this lives that are really difficult for me to answer (partially out of ignorance, partially because they involve a lot of people coming together and deciding what the architecture is). While I'm happy to start discussing those now, I don't think the discussion should become an impediment for implementing something now.
(In reply to comment #7)
> I request that the implementation provide a basis for implementing the user
> interface requested in bug #540194. While that might require more effort, it
> would avoid the greater combined effort needed to implement two Profile
> Managers (one for test and triage and one for users).
I think this is ideal going forward, as there is really no reason to duplicate effort. However, I think setting the target towards an end-user application changes the intention too much. I think it is likely that what is implemented for this bug will be a good basis for end-user profile management. However, I think that should be assessed after the fact and I think it is overkill to make one application with initial requirements of "be good for testing" and "be good for end users". I want to satisfy the "be good for testing" first, although keeping in mind the broader goal. If it is good for testing, it should have a superset of functionality required for users (testers are users too!) and there is no reason to make a bad UI for testers. I think implementing the superset of functionality, which testers will need, with a reasonable UI, will provide a good setup going forward with bug 540194 , but that should really be assessed after this piece is done. Then it becomes meaningful to ask "what do end users need (or don't need) that isn't satisfied by this design?"
Potentially the form of the application could differ based on a make flag if there is a reason to share functionality but have different presentations going forward. But that's too far ahead to think in detail.
The work in progress is here:
- this is not in a usable state; similarly, the README and INSTALL files are out of date (and will be so until things get more solid)
- ... so this is really only useful if you're curious about implementation
- you'll need to build with mozilla-central going forward
- um, did I say "work in progress"? currently this doesn't do anything ;)
Questions and feedback appreciated. The high-level implementation probably isn't going to change, so I'm more interested in actionable items.
Update: The WIP is now at:
Many/most of the features requested here are implemented. Will update on release. This bug now serves as a tracking bug. Additional items should be ticketed in the Testing product under the ProfileManager component.
Will update when the product is released.
(In reply to comment #11)
> Many/most of the features requested here are implemented. Will update on
> release. This bug now serves as a tracking bug. Additional items should be
> ticketed in the Testing product under the ProfileManager component.
> Will update when the product is released.
Thanks Jeff! Can you please add those additional bugs to the dependency list? That would be wonderful. That way we wouldn't have to follow an additional component and can see updates immediately.
Also CC'ing Benjamin so he is aware of your work on the profile manager app.
(In reply to comment #12)
> (In reply to comment #11)
> > Many/most of the features requested here are implemented. Will update on
> > release. This bug now serves as a tracking bug. Additional items should be
> > ticketed in the Testing product under the ProfileManager component.
> > Will update when the product is released.
> Thanks Jeff! Can you please add those additional bugs to the dependency list?
> That would be wonderful. That way we wouldn't have to follow an additional
> component and can see updates immediately.
I looked through https://bugzilla.mozilla.org/buglist.cgi?resolution=---&resolution=DUPLICATE&query_format=advanced&component=ProfileManager&product=Testing and the only necessary blocker for e.g. a beta release I found was bug 590788 which I've added as a dependency here. I'm not sure who should be triaging ProfileManager, but if it's me, then my intention is only to add blocking bugs here that will block a beta release and then to close this ticket following the beta release.
There are also a number of things that are not ticketed items that need to be done that I don't intend to turn into ticketed items. These include but are not limited to:
- getting bsmedberg's and beltzner's feedback
- getting UI feedback
- presenting at the monday meeting
- various review and polish and general testing
I am disinclined to use bugzilla for such things as:
- the project is in a pre-alpha state and noting who should sign off on what is both time-consuming and non-interesting ("Present at monday's meeting" just isn't that productive when you already have that information duplicated in emails, wiki pages, and private communications)
- its a small project with two developers; instead of developing the software right now i'm writing notes in bugzilla. i'd rather be developing the software
- while for large and/or mature projects with many developers, having a robust process where everything is ticketed allows deep introspection necessary to keep an informed audience, for a small immature project developing this level of infrastructure is a huge time sink. Ultimately, tools like bugzilla are here to aid developers in creating great software. But such tools are only useful when they're a burden instead of a help. A full triage of ProfileManager noting every issue right now would take maybe 24 man-hours which could better be spent actually fixing issues
> Also CC'ing Benjamin so he is aware of your work on the profile manager app.
So profilemanager is up and working. We should decide what additionally needs to be done for this bug, do it, and close it so that it doesn't block.
(In reply to comment #14)
> So profilemanager is up and working. We should decide what additionally needs
> to be done for this bug, do it, and close it so that it doesn't block.
I think this bug is closed when we land version 1 of the new profile manager in mozilla-central.
Why would we land it in mozilla-central? I thought the whole point of this is that it's *not* part of Firefox and doesn't need to land in mozilla-central...
Will this have to be in mozilla-central for bug #540194?
What happens with this bug is really irrelevant to what seamonkey does with bug 540194.
> Why would we land it in mozilla-central? I thought the whole point of this is
> that it's *not* part of Firefox and doesn't need to land in mozilla-central...
I'm not quite clear where this will end up eventually. But I had thought that beltzner or mossop had said it might be added to m-c to make it easier to bundle with Firefox....
beltzner and/or mossop, can you clarify?
I don't think we'll be bundling this with Firefox normally and I don't think it should land in mozilla-central.
(In reply to comment #20)
> I don't think we'll be bundling this with Firefox normally and I don't think it
> should land in mozilla-central.
Hmmm...ok. That seems different from what I last heard when we'd talked about this. Last time we'd talked about it we'd talked about reviews and landing it on m-c. If that's changed, so much for the better. The code currently lives in hg.mozilla.org/automation/profilemanager.
It's really a question of whether or not you want the tool bundled with Firefox. If it's bundled then it would be nice to put it in m-c for making that easier. If not, then we can continue to host it in our repo, and we will find a way (perhaps a link on the nightly first run page) to distribute the builds.
The other issue to think about is that if the tool is not in m-c, then we should investigate staging the xpcshell tests for it into some kind of automated system so that we know when/if changes to m-c break the profile manager and we can have automated testing of it.
At this point I do not think we should bundle it, and it should be made available as a separately downloaded application.
I'm sorry to put this in the bug report, but this seems to be the only place where people are talking about this.
As of the January 29 pre-release of 4.0b11, the original UI for the profile manager still exists, activated by the "-p" command line switch when used without naming a profile. It seems that this feature will be removed, and replaced with a separate, more complicated program designed for developers. Am I understanding this correctly?
Because I, as an end user use this feature, would request that the end user UI not be removed until it is replaced by a UI that can easily accomplish the same thing.
Also, while it is not mentioned, am I correct in assuming the "-p" switch will continue to exist, allowing one to pick a profile by name on the command line itself?
(In reply to comment #23)
Terrell, the existing profile manager won't be removed from Firefox until after Firefox 4.0 ships.
If the plan moves forward as anticipated, after removal, Firefox will support the -profile switch (which allows you to pass the path of a profile to Firefox),but not the -P switch (which allows you to pass the name of a profile to Firefox).
Linux users are reporting that the new profile manager appears to be unstyled. It's working perfectly on Windows 7 though.
I found that third-party apps can't find Firefox when it's been launched from the new Profile Manager. The BitDefender Quickscan extension wouldn't run a scan, it couldn't locate the browser it was running in to open a new tab for the scan widget. If I change the default profile with the new Profile Manager, Spyware Blaster no longer detects that Firefox is installed.
Thanks Spencer, I confirmed this problem and filed it as bug 658320
A version 1.0 of this app is available at http://ftp.mozilla.org/pub/mozilla.org/utilities/profilemanager/1.0/.
(In reply to Jonathan Griffin (:jgriffin) from comment #28)
> A version 1.0 of this app is available at
I downloaded the new version (for win32) twice, download was corrupted both times - got errors when I tried to extract it. I'm having no problems with other downloads, or with extracting other .zip files.
(In reply to Spencer Selander [greenknight] from comment #29)
> (In reply to Jonathan Griffin (:jgriffin) from comment #28)
> > A version 1.0 of this app is available at
> > http://ftp.mozilla.org/pub/mozilla.org/utilities/profilemanager/1.0/.
> I downloaded the new version (for win32) twice, download was corrupted both
> times - got errors when I tried to extract it. I'm having no problems with
> other downloads, or with extracting other .zip files.
Can you try this again? I can download and extract on win32 without problems. If the error persist, please let me know what unzip utility you're using.
Any chance of getting a native FreeBSD version?
(In reply to Jonathan Griffin (:jgriffin) from comment #30)
> (In reply to Spencer Selander [greenknight] from comment #29)
> > (In reply to Jonathan Griffin (:jgriffin) from comment #28)
> > > A version 1.0 of this app is available at
> > > http://ftp.mozilla.org/pub/mozilla.org/utilities/profilemanager/1.0/.
> > I downloaded the new version (for win32) twice, download was corrupted both
> > times - got errors when I tried to extract it. I'm having no problems with
> > other downloads, or with extracting other .zip files.
> Can you try this again? I can download and extract on win32 without
> problems. If the error persist, please let me know what unzip utility
> you're using.
Tried again, still no good; ExtractNow, 7-Zip, and the XP Extraction Wizard all said it was corrupt. Previous tries I got a 15.3 MB file that mostly extracted before the error occurred, this time it was 15.0 MB and wouldn't even start to extract.
Used Free Download Manager, I'll try again tomorrow with the Firefox download manager. I'd do it right now, but I'm on dialup and it takes a long time.
(In reply to Spencer Selander [greenknight] from comment #32)
No problems when unpacking following file with 7-Zip 9.20:
Your issue is probably related to your internet connection/provider or hard disk / memory errors or just download manager.
Downloaded again using Firefox DM, no problem. Will do further testing to try and definitely pin down the cause.
(In reply to Spencer Selander [greenknight] from comment #34)
> Downloaded again using Firefox DM, no problem. Will do further testing to
> try and definitely pin down the cause.
Downloaded ok with Free Download Manager as well, so that wasn't the problem. I ran chkdsk before the first successful download, fixed some file system errors - guess that's what did it. Strange that no other downloads had problems.