Closed
Bug 203077
Opened 21 years ago
Closed 20 years ago
Rename "Phoenix" profile folder to "Firefox"
Categories
(Firefox :: General, defect)
Firefox
General
Tracking
()
VERIFIED
FIXED
People
(Reporter: ts, Assigned: bugs)
References
Details
Attachments
(3 files, 2 obsolete files)
3.56 KB,
patch
|
Details | Diff | Splinter Review | |
3.76 KB,
patch
|
Details | Diff | Splinter Review | |
32.01 KB,
patch
|
jst
:
review+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4a) Gecko/20030423 Firebird/0.6 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4a) Gecko/20030423 Firebird/0.6 Rename "phoenix" profile folder to "firebird" Reproducible: Always Steps to Reproduce:
Comment 1•21 years ago
|
||
My suggestion (well, not just mine) is to change the profile folder to Mozilla/Firebird. This way, we can keep all profile folders for Mozilla in one parent folder.
OS: Windows 2000 → All
Comment 3•21 years ago
|
||
Makes sense. So on win32 we get, Mozilla\Firebird\ and on Linux we'll have .mozilla/firebird. But where would a Mozilla Suite profile go then? Mozilla\Suite? Until then, Phoenix still needs to be renamed to Firebird, as was the case for Minotaur and Thunderbird. Confirming Blocks 202233 Should a milestone of 0.6 be set on this?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Rename "Phoenix" profile folder to "firebird" → Rename "Phoenix" profile folder to "Firebird"
Comment 4•21 years ago
|
||
*** Bug 206137 has been marked as a duplicate of this bug. ***
Comment 5•21 years ago
|
||
Better proposal, if we want to be forward-looking, we can use Mozilla/Browser for the profile directory. There's no naming conflict with Mozilla Navigator (AppSuite) and would prevent having to go back and change things before 1.0. This could be used for a convention whereby Thunderbird could use Mozilla/Mail and other apps could work that way.
Comment 6•21 years ago
|
||
I agree with the common scense of placing all profile folders under the Mozilla Root. This becaue Mozilla is now equivalent to a software company and aggregating all it's products under sommon root folder will enhance brand association.
Updated•21 years ago
|
QA Contact: asa
Comment 7•21 years ago
|
||
*** Bug 225138 has been marked as a duplicate of this bug. ***
Comment 8•21 years ago
|
||
*** Bug 226239 has been marked as a duplicate of this bug. ***
Comment 9•21 years ago
|
||
*** Bug 226542 has been marked as a duplicate of this bug. ***
Comment 10•21 years ago
|
||
not something that would block 0.8, since its transparent to the user, but I'm sure it will be fixed for 1.0
Flags: blocking0.8? → blocking0.8-
Comment 11•21 years ago
|
||
The name of the user directory is hard-coded to Phoenix here: http://lxr.mozilla.org/mozilla/source/browser/app/nsBrowserApp.cpp#48 Confirmed by this code: http://lxr.mozilla.org/mozilla/source/toolkit/xre/nsXULAppAPI.h#61 Also, setting Severity to trivial as there's no loss of function for the vast majority of users (and the ones who might be disoriented should figure out very quickly what's happened). Feel free to change back if you disagree for some extraordinary reason.
Severity: normal → trivial
Flags: blocking0.8- → blocking0.8?
Updated•20 years ago
|
Summary: Rename "Phoenix" profile folder to "Firebird" → Rename "Phoenix" profile folder to "Firefox"
Comment 13•20 years ago
|
||
There is already a configure flag for MOZ_USER_DIR can we patch the source to use this instead of the current silliness? In trying to transition from 0.7 to 0.8 on Gentoo, I had intended on making the change to .firefox instead of .phoenix (the suggested .mozilla/firefox would be acceptable as well) but found that the --with-user-dir=".firefox" configure flag did little to nothing (results in the creation of an empty .firefox directory each run, but no files are created) after attempting to dig through the source, I finally found this bug. Aside from this issue, there is the further issue that throughout the source, there are hardcoded references to .mozilla which should most likely be replaced with snprintfs from MOZ_USER_DIR as defined at configure time. I hope I'm not out of line for these comments, just a lowly packager here.
Comment 14•20 years ago
|
||
I was disappointed when loading up firefox 0.8 for the first time and seeing that it is still using the Phoenix folder. Is there a valid reason for this? Because for me it is a basic usability problem, especially for new users/developers who don't know about the pre-existence of Phoenix. This is not a trivial issue.
Severity: trivial → normal
Updated•20 years ago
|
Flags: blocking0.9?
Comment 15•20 years ago
|
||
the reason its trivial is because normal users never see this. those who do end up needing this info can check the various help resources which correctly identify the path. changing it would just mean all old profiles would be gone/have to be imported. I don't think we're ready to do that just yet, but it would be good to do just before 1.0, once the profile format is much more solid and we want to enforce users creating new profiles.
Severity: normal → trivial
QA Contact: mconnor
Comment 16•20 years ago
|
||
*** Bug 234839 has been marked as a duplicate of this bug. ***
Comment 17•20 years ago
|
||
I created a patch which makes a client.mk variable called PHOENIX_DIR, then uses that instead of hardcoding to "Phoenix" in browser/app/nsBrowserApp.cpp in client.mk it defaults to Phoenix incase PHOENIX_DIR is unset in .mozconfig
Comment 18•20 years ago
|
||
I created a patch which makes a client.mk variable called PHOENIX_DIR, then uses that instead of hardcoding to "Phoenix" in browser/app/nsBrowserApp.cpp in client.mk it defaults to Phoenix incase PHOENIX_DIR is unset in .mozconfig
Comment 19•20 years ago
|
||
(sorry for posting twice... acident) to use this just add export PHOENIX_DIR=Firefox mk_add_options PHOENIX_DIR=Firefox to your .mozconfig file if you want plugins in same directory add ac_add_options --with-user-appdir=.firefox
Comment 20•20 years ago
|
||
Comment on attachment 141937 [details] [diff] [review] turns hardcoded "Phoenix" into a client.mk variable my patch doesn't work, i built it and it screws up after a long time of building...
Attachment #141937 -
Attachment is obsolete: true
Comment 21•20 years ago
|
||
this patch creates a new configure option, which creates a file called product.h this is included in nsBrowserApp.cpp, it defines a macro for the name to replace "Phoenix" just add ac_add_options --with-product-name=(name) defaults to Phoenix
Attachment #141938 -
Attachment is obsolete: true
Comment 22•20 years ago
|
||
Comment on attachment 142110 [details] [diff] [review] rename patch that works This patch does not account for the problem on Linux, Unix, or OS X. When this is fixed, it needs to be fixed on all platforms on the same time.
Comment 23•20 years ago
|
||
does http://lxr.mozilla.org/seamonkey/search?string=MOZ_USER_DIR have any relevance ? ends up in the shell script to start my cvs builds on Linux : MOZ_USER_DIR=".phoenix"
Comment 24•20 years ago
|
||
my latest patch does work on all os, just add --with-product-name=Firefox to change the profile dir, and if you want plugins to be in same directory, add --with-user-appdir=.firefox
Comment 25•20 years ago
|
||
(In reply to comment #24) > my latest patch does work on all os, just add --with-product-name=Firefox to > change the profile dir, and if you want plugins to be in same directory, add > --with-user-appdir=.firefox after applying patch [ attachment 14211 [details] ] --with-product-name=Firefox bit works for me Linux and Mac OS X
Comment 26•20 years ago
|
||
configure changed in cvs - patch no longer works
Comment 27•20 years ago
|
||
(In reply to comment #26) > configure changed in cvs - patch no longer works I am working on this, my comuter crashed, so I havn't had time will be new patch soon
Comment 28•20 years ago
|
||
Comment 29•20 years ago
|
||
Fixed by Ben today (bonsai link below): http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=PhoenixTinderbox&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=03%2F04%2F2004+16%3A00%3A00&maxdate=03%2F04%2F2004+16%3A43%3A00&cvsroot=%2Fcvsroot
Status: NEW → RESOLVED
Closed: 20 years ago
Hardware: PC → All
Resolution: --- → FIXED
Comment 30•20 years ago
|
||
I cannot verify fix because it crashes when start with non-existent profile.
Comment 31•20 years ago
|
||
I get the same results in Comment #30 upon running 'firefox -profilemanager'
Comment 32•20 years ago
|
||
-> Reopening since Ben backed this out to fix Tinderbox orange.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 33•20 years ago
|
||
try setting the environment variable, becuase he uses a variable which allows for dynamic changes in profile directory
Comment 34•20 years ago
|
||
*** Bug 236935 has been marked as a duplicate of this bug. ***
Assignee | ||
Updated•20 years ago
|
Assignee: firefox → bugs
Status: REOPENED → NEW
Assignee | ||
Comment 35•20 years ago
|
||
Summary of changes: Index: browser/app/nsBrowserApp.cpp - change profile folder name from "Phoenix" to "Firefox" Index: browser/components/migration/content/migration.js - import item flags is now a 16-bit bit field, not a 32-bit field, also adapt code to set the migrate flags to be all the data that the default migrator can support in automigrate mode. Index: browser/components/migration/locale/migration.properties - add strings for the phoenix->firefox profile migrator Index: browser/components/migration/public/nsIBrowserProfileMigrator.idl - 32-bit field -> 16-bit field Index: browser/components/migration/src/ns*ProfileMigrator.cpp - 32-bit field -> 16-bit field (PRInt32 -> PRInt16) Index: browser/components/migration/src/nsProfileMigrator.cpp - only migrate if we got a migrator and a migration source exists Index: xpfe/appshell/src/nsAppShellService.cpp - When there are 0 profiles, there are three startup cases - (A) is when there are no command line flags specified or there are flags that relate to there being profiles but there are none (e.g. firefox -P profile - but no profiles exist so this is effectively the same as running with no args) (B) is when the app is started with -CreateProfile "foo" (creates profile "foo" and quits) (C) is when the app is started with -ProfileWizard. In B and C, showing the automigration UI is undesirable since the user explicitly does NOT want data migrated (they're creating a new blank profile either from the command line or are using the wizard to do so). Showing the UI at this point breaks automation also, so it needs to be disabled.
Comment 36•20 years ago
|
||
Comment on attachment 143559 [details] [diff] [review] change profile folder name, and fix automigation so that automation works browser/components/migration/content/migration.js var MigrationWizard = { _source: "", // Source Profile Migrator ContractID suffix - _itemsFlags: kIMig.ALL, // Selected Import Data Sources (32-bit bitfield) + _itemsFlags: kIMig.ALL, // Selected Import Data Sources (16-bit bitfield) _selectedProfile: null, // Selected Profile name to import from Nit of the day, fix the indentation. r=jst (with the 5s delay and activated Finish button, as discussed offline).
Attachment #143559 -
Flags: review+
Assignee | ||
Comment 37•20 years ago
|
||
Alright, fixed again.
Status: NEW → RESOLVED
Closed: 20 years ago → 20 years ago
Resolution: --- → FIXED
How can the end-user verify that this is fixed? Will this code be present in anything built with a date of 20040312?
Comment 39•20 years ago
|
||
I've a problem with the way of importing the profiles from the old phoenix folder. For testing puposes I use different profiles and all of them should be assigned to the new registry.dat. At the moment I see only a radio button field where I can select only one profile. Indeed we should offer checkboxes so that Firefox converts all profiles the user has. After the migration to the new profile directory I didn't have the chance to run this dialog again and I lose the other profiles. Thats not a good idea because a lot of people use multiple profiles for one windows user. Should we reopen this bug or better create a new one?
I'm guessing that a new bug is probably a good idea. I didn;t use profile migration anyway when I went from 20040229 to 20040311; I just blew everything away and rebuilt it from scratch. Removing self from CC list.
Comment 41•20 years ago
|
||
So I start up todays build and I get a dialog box saying that "Import was complete and the following items were imported". Huh? What the hell happened? WHat Import? I didn't ask for any Import. Before I have a chance to get over my shock and read through the list of things it imported, the dialog box disappears and Firefox starts up. umm.. okay.. I start using Firefox and discover that all my plugins are gone, my form fill info is gone and all of a sudden its warning me with a dialog box when I try to close a window with multiple tabs. I had disabled that prompt ages ago. I use nightlies so I can't complain much but I hope these issues would be fixed for people migrating from 0.8 to 0.9.
Comment 42•20 years ago
|
||
fyi. For people getting bitten by this bug, the following might help. 1. Delete the newly .firefox directory created 2. Copy .phoenix over to .firefox 3. Find all files that contain .phoenix and change it to .firefox. In my case I needed to change 2 files .firefox/default/random.slt/chrome/chrome.rdf and appreg. Although appreg is a binary file, I could edit it and it didn't cause any problems. Maybe because firefox and phoenix are both 7 letter words. I don't know. 4. Delete XUL.mfasl Restart Firefox and everythings good.
Comment 43•20 years ago
|
||
Pratik, I know this way but my minds are by normal users whose don't know about any inner life of Firefox. You can't say that they have to edit the profile files! At this stage I think that all profiles have to be converted to the new directory. Why should we get a dialog where we can manually choose the profile? If somebody has multiple profiles he also wants to work with them in the new Firefox versions. Otherwise I believe that many people would be frustrated and perhaps change back to OE or other software! In the last days I already heard as much of such problems (eg. moving a profile to a new partition).
Updated•20 years ago
|
Flags: blocking0.9?
Comment 45•20 years ago
|
||
*** Bug 245028 has been marked as a duplicate of this bug. ***
Comment 46•20 years ago
|
||
*** Bug 245777 has been marked as a duplicate of this bug. ***
You need to log in
before you can comment on or make changes to this bug.
Description
•