Closed Bug 203077 Opened 21 years ago Closed 20 years ago

Rename "Phoenix" profile folder to "Firefox"

Categories

(Firefox :: General, defect)

defect
Not set
trivial

Tracking

()

VERIFIED FIXED

People

(Reporter: ts, Assigned: bugs)

References

Details

Attachments

(3 files, 2 obsolete files)

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:
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
Blocks Bug 202233, remove if you disagree
Blocks: 202233
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"
*** Bug 206137 has been marked as a duplicate of this bug. ***
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.
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.
QA Contact: asa
*** Bug 225138 has been marked as a duplicate of this bug. ***
*** Bug 226239 has been marked as a duplicate of this bug. ***
*** Bug 226542 has been marked as a duplicate of this bug. ***
Flags: blocking0.8?
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-
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?
Hmm...why did it set a blocking flag there?
Flags: blocking0.8?
Summary: Rename "Phoenix" profile folder to "Firebird" → Rename "Phoenix" profile folder to "Firefox"
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.
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
Flags: blocking0.9?
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
*** Bug 234839 has been marked as a duplicate of this bug. ***
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
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
(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 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
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 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.
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"
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
(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
configure changed in cvs - patch no longer works
(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
I cannot verify fix because it crashes when start with non-existent profile.
I get the same results in Comment #30 upon running 'firefox -profilemanager'
-> Reopening since Ben backed this out to fix Tinderbox orange.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
try setting the environment variable, becuase he uses a variable which allows
for dynamic changes in profile directory
*** Bug 236935 has been marked as a duplicate of this bug. ***
Assignee: firefox → bugs
Status: REOPENED → NEW
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 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+
Alright, fixed again. 
Status: NEW → RESOLVED
Closed: 20 years ago20 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?
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.
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.
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.
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).
verified.
Status: RESOLVED → VERIFIED
Flags: blocking0.9?
*** Bug 245028 has been marked as a duplicate of this bug. ***
*** 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.