Closed Bug 171561 Opened 22 years ago Closed 20 years ago

Mozilla Firefox creates a profile directory called "Mozilla"

Categories

(Firefox Build System :: General, defect)

Product:
Firefox Build System
Component:
General
Type:
defect
Priority:
Not set
Severity:
trivial

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
Firefox0.9

People

(Reporter: nathans, Assigned: bugs)

References

Details

(Whiteboard: fixed-aviary1.0)

Attachments

(1 file, 8 obsolete files)

all patches rolled up
8.84 KB, patch
Details | Diff | Splinter Review
If there is no profile directory named "Mozilla", Phoenix creates an empty one. It will be something like: C:\Documents and Settings\UserName\Application Data\Mozilla The normal, Phoenix, profile directory is also present.
Nathan, always include the version or date of the build you tested. This should have been fixed already. If you're using the latest nightly and you can still reproduce then please reopen.
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago
Resolution: --- → WORKSFORME
This happened with the latest nightly build, 27-Sep-2002 15:33. It happens on Windows XP Pro as well as Windows 98.
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
can you try this again with a current nightly build (29th or newer). A lot happens in a short period of time on this project. Thanks.
Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.2b) Gecko/20020929 Phoenix/0.2 I can confirm this still happens with a build from the 29th. Installed Phoenix. Checked and found Phoenix and Mozilla profile dirs. Exited Phoenix, deleted Phoenix and Mozilla directories. Restarted Phoenix, checked for the profile directories again and both were there.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2b) Gecko/20020930 Phoenix/0.2 Hi Asa, this is still happening with today's build, 30-Sep-2002 09:23. Tobias was also able to dupe it. I am going to change the status from UNCONFIRMED to NEW.
Ahhh, I'm not allowed to change the status. Someone else can do it.
Confirming Bug on Win95 with Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.2b) Gecko/20020930 Phoenix/0.2 havn't tray under linux ... will do it todays evening. (There is no All Windows in OS but I won't change OS to All yet.)
Setting bug status to new. This regressed, probably because of the XRE changes. We should get this fixed for 0.3.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Target Milestone: --- → Phoenix0.3
-> build?
Assignee: blaker → bryner
Component: General → build-config
This seems minor enough to shove off.
Target Milestone: Phoenix0.3 → Phoenix0.4
Linux is making an empty .mozilla as well. Phoenix 0.3. (0.3 is fantastic guys. Great work.)
OS: Windows XP → All
Target Milestone: Phoenix0.4 → Phoenix0.5
Target Milestone: Phoenix0.5 → Phoenix0.6
Yes, I'd say those #defines are it, though the line numbers are off by a few.
*** Bug 190021 has been marked as a duplicate of this bug. ***
Could it be that this is also the reason for the password-doubling problem described at http://www.mozillazine.org/forums/viewtopic.php?t=1698 ? It seems that px is not only creating that directory, but also reading from it.
maybe 0.7
Target Milestone: Phoenix0.6 → Phoenix0.7
Summary: Phoenix creates a profile directory called "Mozilla" → Mozilla Firebird creates a profile directory called "Mozilla"
See bug 172891 comment 3.
Blocks: 172891
--with-user-appdir was recently fixed (bug 58327) so Firebird should be able to use that option to avoid the defaults of "Mozilla" & ".mozilla". I'm not sure how/why it's using "Phoenix" on OSX atm.
Target Milestone: Firebird0.7 → Firebird0.8
QA Contact: asa
This is still broken from 10/23 CVS. I attempted to locate the code that is doing this VIA LXR but no luck. Anybody have any idea where this is happening?
Chris: I suggest reading this bug, especially comment 12 and comment 17.
Target Milestone: Firebird0.8 → Firebird0.9
This isn't really that big a deal, -->trivial. (cf. bug 203077)
Severity: normal → trivial
Summary: Mozilla Firebird creates a profile directory called "Mozilla" → Mozilla Firefox creates a profile directory called "Mozilla"
(In reply to comment #21) > This isn't really that big a deal, -->trivial. (cf. bug 203077) True, but it is of more importance to system administrators with lots of network clients. At the very least it is an annoyance and it just makes it looks sloppy. I don't care what milestone it gets fixed in, but it should definate pre 1.0 fix.
Attached patch v1.0 (obsolete) — — Splinter Review
Since we use different names for different platforms, using --with-user-appdir isn't a viable solution even though every app has its own mozconfig file. So, hardcode the names similar to what we do for MOZ_APP_NAME. These hardcoded names can still be overridden by --with-user-appdir.
Attachment #143698 - Flags: review?(bryner)
Attached patch v1.1 (obsolete) — — Splinter Review
Helps alot if I add the . before the unix direcotry names.
Attachment #143698 - Attachment is obsolete: true
Attachment #143698 - Flags: review?(bryner)
Attachment #143749 - Flags: review?(bryner)
Comment on attachment 143749 [details] [diff] [review] v1.1 Does this also cause it to look for plugins in ~/.firefox/plugins rather than ~/.mozilla/plugins?
Yes. Anything that uses the nsAppFileLocationProvider will be affected.
Attachment #143749 - Flags: review?(bryner)
Attached patch v1.2 (obsolete) — — Splinter Review
And beos.
Attachment #143749 - Attachment is obsolete: true
Attachment #144442 - Flags: review?(bryner)
(From attachment 144442 [details] [diff] [review]:) > --- configure.in 19 Mar 2004 16:59:48 -0000 1.1327 > +++ configure.in 21 Mar 2004 11:19:57 -0000 > @@ -3363,6 +3363,18 @@ > AC_DEFINE(MOZ_XUL_APP) > MOZ_APP_NAME=firefox > MOZ_APP_VERSION=`cat $topsrcdir/browser/config/version.txt` > + case "$target_os" in > + cygwin*|mingw*|msvc*|mks*|os2*|darwin*|beos*) > + if test -n "$_X11_TOOLKIT"; then > + MOZ_USER_DIR=.firefox > + else > + MOZ_USER_DIR=Firefox > + fi > + ;; > + *) > + MOZ_USER_DIR=.firefox > + ;; > + esac > fi Erm... doesn't firefox use ".phoenix" as profile dir name ? > @@ -3395,6 +3419,18 @@ > AC_DEFINE(MOZ_XUL_APP) > MOZ_APP_NAME=nvu > MOZ_APP_VERSION=0.17+ > + case "$target_os" in > + cygwin*|mingw*|msvc*|mks*|os2*|darwin*|beos*) > + if test -n "$_X11_TOOLKIT"; then > + MOZ_USER_DIR=.composer > + else > + MOZ_USER_DIR=Composer > + fi > + ;; > + *) > + MOZ_USER_DIR=.composer > + ;; > + esac > fi This screams for trouble, too... "composer" is a very very generic name... this may end-up in a collision with other applications. What about using ".mozcomposer" ? Two more problems: 1. What about "calendar" (e.g. "SunBird" or whatever it's name is right now) 2. If Makefile.in now itself knows about the value of MOZ_USER_DIR the following hardcoded values can be removed: http://lxr.mozilla.org/seamonkey/source/xpfe/bootstrap/Makefile.in#381 379 $(MOZILLA_SCRIPT):: mozilla.in Makefile.in Makefile $(DEPTH)/config/autoconf.mk 380 cat $< | sed -e "s|%MOZAPPDIR%|$(mozappdir)|" \ 381 -e "s|%MOZ_USER_DIR%|.mozilla|" \ 382 -e "s|%MREDIR%|$(mredir)|" \ 383 -e "s|%MOZILLA-BIN%|$(PROGRAM)|g" > $@ 384 chmod +x $@ ... similar stuff sits in mozilla/browser/app/Makefile.in for FireFox... -- snip -- firefox:: mozilla.in Makefile.in Makefile $(DEPTH)/config/autoconf.mk cat $< | sed -e "s|%MOZAPPDIR%|$(mozappdir)|" \ -e "s|%MOZ_USER_DIR%|.phoenix|" \ -e "s|%MREDIR%|$(mredir)|" \ -e "s|%MOZILLA-BIN%|$(PROGRAM)|g" > $@ chmod +x $@ -- snip -- ... and ThunderBird... -- snip -- thunderbird:: mozilla.in Makefile.in Makefile $(DEPTH)/config/autoconf.mk cat $< | sed -e "s|%MOZAPPDIR%|$(mozappdir)|" \ -e "s|%MOZ_USER_DIR%|.thunderbird|" \ -e "s|%MREDIR%|$(mredir)|" \ -e "s|%MOZILLA-BIN%|$(PROGRAM)|g" > $@ chmod +x $@ -- snip --
> Erm... doesn't firefox use ".phoenix" as profile dir name ? As of a couple weeks ago, Firefox uses "firefox" on Windows, so I would think *nix operating systems switched over to ".firefox" too.
Yup, my Linux nightlies suggest it happened on 5th March.
(In reply to comment #28) > This screams for trouble, too... "composer" is a very very generic name... this > may end-up in a collision with other applications. > What about using ".mozcomposer" ? Composer already sets it's appname as "Composer" per http://lxr.mozilla.org/mozilla/source/composer/app/nsComposerApp.cpp#50 so I was following the convention set by the rest of the apps. Composer is a generic term but I doubt it's going to conflict with any other apps. Doesn't matter to me. We could just as well use .nvu but I'll leave that up to Glazman. > Two more problems: > 1. What about "calendar" (e.g. "SunBird" or whatever it's name is right now) When we add hooks for building the standalone calendar app, then we'll worry about calendar. > 2. If Makefile.in now itself knows about the value of MOZ_USER_DIR the > following hardcoded values can be removed: It doesn't. MOZ_USER_DIR is still a cpp define. If MOZ_USER_DIR were made into a Makefile define, those other hardcoded values could be removed.
(In reply to comment #31) > (In reply to comment #28) > > > This screams for trouble, too... "composer" is a very very generic name... this > > may end-up in a collision with other applications. > > What about using ".mozcomposer" ? > > Composer already sets it's appname as "Composer" per > http://lxr.mozilla.org/mozilla/source/composer/app/nsComposerApp.cpp#50 so I was > following the convention set by the rest of the apps. Composer is a generic > term but I doubt it's going to conflict with any other apps. Doesn't matter to > me. We could just as well use .nvu but I'll leave that up to Glazman. I fear this will cause sooner or later big trouble... profile dir names should always be made from (at least) two words ("thunder"-"bird", "fire"-"fox") or completely artificial terms (like "mozilla"). > > Two more problems: > > 1. What about "calendar" (e.g. "SunBird" or whatever it's name is right now) > > When we add hooks for building the standalone calendar app, then we'll worry > about calendar. It seems the calendar folks already setup the hooks for the standalone app... see http://lxr.mozilla.org/mozilla/source/calendar/sunbird/app/ > > 2. If Makefile.in now itself knows about the value of MOZ_USER_DIR the > > following hardcoded values can be removed: > > It doesn't. MOZ_USER_DIR is still a cpp define. If MOZ_USER_DIR were made into > a Makefile define, those other hardcoded values could be removed. xx@@@!!!... can you make it a Makefile.in define, please ?
(In reply to comment #32) > I fear this will cause sooner or later big trouble... profile dir names should > always be made from (at least) two words ("thunder"-"bird", "fire"-"fox") or > completely artificial terms (like "mozilla"). Or just stuck under a common mozilla directory but whatever. > > > Two more problems: > > > 1. What about "calendar" (e.g. "SunBird" or whatever it's name is right now) > > > > When we add hooks for building the standalone calendar app, then we'll worry > > about calendar. > > It seems the calendar folks already setup the hooks for the standalone app... > see http://lxr.mozilla.org/mozilla/source/calendar/sunbird/app/ Those aren't hooks. That's the actual standalone code. The MOZ_PHOENIX/MOZ_THUNDERBIRD/MOZ_STANDLAONE_COMPOSER defines in configure.in/client.mk are hooks.
(In reply to comment #32) > I fear this will cause sooner or later big trouble... profile dir names should > always be made from (at least) two words ("thunder"-"bird", "fire"-"fox") or > completely artificial terms (like "mozilla"). How many documents do we have saying "if you want to hack our product so it does this and that, apply the following change to prefs.js or another file in your profile" ? This ****implies**** that the name of the profile must be 100% meaningful for people seeing only the name of the product. Hence the profile's name of Composer. Nvu uses ".nvu". So what is this but about please ? The title of the bug seems to be inaccurate since it does not reflect what the patch is trying to do. Are you trying to centralize the name of the profile somewhere ? If you do, please do NOT make the confusion between Standalone Composer (ie what is in cvs.mozilla.org right now) and Nvu.
(In reply to comment #34) > So what is this but about please ? The title of the bug seems to be inaccurate > since it does not reflect what the patch is trying to do. Are you trying to > centralize the name of the profile somewhere ? If you do, please do NOT make the > confusion between Standalone Composer (ie what is in cvs.mozilla.org right now) > and Nvu. The problem is that firefox and the other standalone apps are still referencing the default mozilla user-application directory (~/.mozilla on linux or %APPDATA%/Mozilla on win32 (or something like that)). This is a user visible problem as the user-application directory is created automatically even if it's not used directly (firefox uses ~/.firefox for everything else). So, the bug summary is a sympton of the actual problem. The patch changes the user-application directory default for all of the standalone apps with hooks into our build system. Other apps will have to use --with-user-appdir to override the defaults.
*** Bug 239342 has been marked as a duplicate of this bug. ***
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040403 Firefox/0.8.0+ (daihard: XFT+GTK2; opt. for P4/SSE-2) This bug is still present. Not only that, but Firefox appears to be fully capable of utilizing .mozilla (I can put plugins in .mozilla and Firefox will load them). Should this block 0.9, or is it too trivial?
Ben and I discussed how we can avoid forcing users to manually copy plugins from ~/.mozilla to ~/.firefox. One idea that seems reasonable is that we move the profile locations as follows: ~/.firefox --> ~/.mozilla/firefox ~/.thunderbird --> ~/.mozilla/thunderbird and if someone wants to do the work, ~/.mozilla --> ~/.mozilla/seamonkey then all applications could have ~/.mozilla/plugins as the plugin location. One issue here is that the app names could potentially (though unlikely) collide with existing seamonkey profile names. We could prefix the app names with a '.' or somesuch to make this even more unlikely, though I'd prefer to get away from "hidden" files once we're below the user's home directory. We would probably not provide automatic migration from ~/.firefox to ~/.mozilla/firefox since the former location has not yet shipped in a release.
That sounds like a good idea, and a good part of the new comprehensive branding strategy embraced by the Foundation. But what will the devs do with .mozilla now? ATM putting my plugins in .mozilla is best because I'm constantly updating to new nightlies and nuking my firefox and .firefox directories (strangely enough, plugins don't work in .firefox/plugins, but that's a separate issue).
Comment on attachment 144442 [details] [diff] [review] v1.2 Minusing based on the new plan I mentioned.
Attachment #144442 - Flags: review?(bryner) → review-
Brian Ryner (IBM) wrote: > Ben and I discussed how we can avoid forcing users to manually copy plugins > from ~/.mozilla to ~/.firefox. One idea that seems reasonable is that we move > the profile locations as follows: > ~/.firefox --> ~/.mozilla/firefox > ~/.thunderbird --> ~/.mozilla/thunderbird Sounds nice... :) 1. If you are worried about profile name collisions... what about adding a prefix (e.g. ~/.mozilla/greapp_firefox/) or a postfix (~/.mozilla/firefox_profiles/) to the application name (but I doubt that a collision can occur since the user profiles always have the extra "salt" subdir) ? 2. When you make the patch - can you please update the framework for the init.d/ scripts (e.g. adjust the profile locations in the Makefile.in), too ?
I have a problem with the ~/.mozilla/plugins proposal... A standalone 3rd-party application tool based on Gecko and using plugins would have to rely on that but would obviously NOT live into ~/.mozill& itself. So my question is the following one: is it ~/.mozilla/plugins or ~/.gecko/plugins ?
> then all applications could have ~/.mozilla/plugins as the plugin location. You're assuming that all gecko based apps want to share a common user plugin directory. While that's a safe assumption for some apps released by mozilla.org, that's probably not the case universally. (Yeah, I know. "WFM. Hack the code. YMMV.") Right now, it's easy enough to create a common plugin dir by setting MOZ_PLUGIN_PATH but with these changes, there'd be no way to have app specific plugins short of installing them with the application. > But what will the devs do with .mozilla now? ATM putting my plugins in .mozilla > is best because I'm constantly updating to new nightlies and nuking my firefox > and .firefox directories (strangely enough, plugins don't work in > .firefox/plugins, but that's a separate issue). Actually, it's the same issue. The plugins don't work in ~/.firefox/plugins because the plugins code still uses the default values set in nsDirectoryService which is ~/.mozilla/. I'm still not certain why the new-world apps decided to only override a portion of the user appdir defaults. To fix this for seamonkey (since it was listed as an afterthought), the defaults in nsDirectoryService would probably change. New-world apps won't care since they're not using them anyway. Other gecko-based apps might, especially if we're forced to hardcode ~/.mozilla in as the user app data name and use a separate variable for the application specific directory.
Does this mean that Firefox can be built to look in ~/.firefox/plugins instead of ~/.mozilla/plugins with the use of a .mozconfig instead of a diff?
Yes, that was the original fix that I suggested in comment #18. However, since we use different appdir names based upon platforms, just adding the change to browser/config/mozconfig won't work unless someone knows the jooky to auto-detect the target platform in the .mozconfig file.
(In reply to comment #43) > > then all applications could have ~/.mozilla/plugins as the plugin location. > > You're assuming that all gecko based apps want to share a common user plugin > directory. Sorry, I didn't specify that clearly enough. What we'd discussed was: ~/.<vendor>/plugins ~/.<vendor>/productFoo similar to Application Data\ on Windows. > I'm still not certain why the new-world apps decided to > only override a portion of the user appdir defaults. It wasn't intentional, actually. But now that we have people using Firefox with their plugins in ~/.mozilla/plugins, we sort of need to not break that.
Mac OS X 10.3.3 was also reproduced. Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; ja-JP; rv:1.7b) Gecko/20040404 Firefox/0.8.0+
Hardware: PC → All
> It wasn't intentional, actually. But now that we have people using Firefox with > their plugins in ~/.mozilla/plugins, we sort of need to not break that. *sigh* Given that firefox is still pre-0.9, why are we turning an unintentional side-effect into a design decision? A per vendor directory sounds great but I don't agree that every vendor wants to use the same plugins across their apps. But mozilla.org's apps probably do so we'll ship that. Given that firefox 0.9 & 1.0 are going to be based out of the mozilla 1.7 "stable" branch, are we going to have enough time to implement the changes to the Directory Service and whatever else needs to be touched in the new apps before 1.7 branches?
(In reply to comment #48) > > It wasn't intentional, actually. But now that we have people using Firefox with > > their plugins in ~/.mozilla/plugins, we sort of need to not break that. > > *sigh* Given that firefox is still pre-0.9, why are we turning an unintentional > side-effect into a design decision? Ok, that was a poor rationale. A better one is that Firefox aims to provide seamless migration from Seamonkey. We either need to figure out a way to migrate the plugins, or stick with the old plugin location. A per vendor directory sounds great but I > don't agree that every vendor wants to use the same plugins across their apps. > But mozilla.org's apps probably do so we'll ship that. They can implement nsIDirectoryServiceProvider. > Given that firefox 0.9 & 1.0 are going to be based out of the mozilla 1.7 > "stable" branch, are we going to have enough time to implement the changes to > the Directory Service and whatever else needs to be touched in the new apps > before 1.7 branches? > I don't see why that would be a requirement; this all seems like the changes can be restricted to toolkit/xre/nsXREDirProvider.cpp rather than changing the #defines (which actually breaks sharing libxpcom between applications).
> > Given that firefox 0.9 & 1.0 are going to be based out of the mozilla 1.7 > > "stable" branch, are we going to have enough time to implement the changes to > > the Directory Service and whatever else needs to be touched in the new apps > > before 1.7 branches? > > > > I don't see why that would be a requirement; this all seems like the changes can > be restricted to toolkit/xre/nsXREDirProvider.cpp rather than changing the > #defines (which actually breaks sharing libxpcom between applications). > Because seamonkey doesn't use toolkit/ . The defines need to be moved out of xpcom because they are really app-specific. The question is do we do that now so that we don't have a huge disparity between seamonkey & the new-world apps on our poorly timed, long lived 1.7 branch or do we wait until 1.8? Or is the answer that seamonkey needs to start implementing its own nsIDirectoryServiceProvider as well which seems like a big change for 1.7.
cls, please stop grinding that axe. Even if 1.7 as stable branch were announced earlier, I doubt we'd have done what you seem to want. There's no way given the new apps' schedules we'd base them off a 1.8 stable branch. Why not do what bryner proposes in comment 38? /be
brendan, please pay attention to the discussion and stop having knee jerk reactions to comments that do not meet your approval. We *are* discussing bryner's proposal from comment #38. We could go off on a whole separate tangent about the prematureness of the stable branch but that's not exactly being productive (here at least). To answer your question directly, his proposal requires considerably more work with potentially further reaching effects (like changing xpcom) on the seamonkey side of things than the new-world apps (from my understanding). If I'm wrong, then please correct me. And if I'm correct, then as a driver, can you tell me if these are the kind of changes that we can get into 1.7 at the last minute or into the 1.7 (or any) stable branch at all or should we punt on the proposal? Or will we be left with the disparity between firefox and any other gecko app since per the clarification from comment #46, we are not talking about just a firefox profile location change but a change to the way all gecko apps handle user profiles.
If I can still contribute anything to this discussion, then from my point of view I believe a wallpaper patch for the 1.7 trunk (and Firefox 0.9 and 1.0, if I understand things correctly) which disables the creation of ~/.mozilla and allows Firefox to read plugin files in ~/.firefox/plugins would temporarily solve the issue that this bug was created for. Then this bug could be used as a tracker for deciding the best way to handle the issue in general. Is that OK?
didn't .firefox ship with 0.8? In any case, the semi-single-profile stuff can fix this to whatever directory scheme we decide upon (assuming I can get reviews). I have some significant alterations to the nsXREDirProvider, so I would like to make this patch once people decide what's best. Note that this can affect embedders as well... are we supposed to have a single location for all gecko-based apps to look for plugins or not? If so, what's wrong with keeping the .firefox / .mozilla dichotomy?
(In reply to comment #54) > didn't .firefox ship with 0.8? No, I believe Ben changed the directory location when the new migration system was checked in. There was a large sticky thread in Firefox General about it. > > In any case, the semi-single-profile stuff can fix this to whatever directory > scheme we decide upon (assuming I can get reviews). I have some significant > alterations to the nsXREDirProvider, so I would like to make this patch once > people decide what's best. Note that this can affect embedders as well... > are we supposed to have a single location for all gecko-based apps to look > for plugins or not? If so, what's wrong with keeping the .firefox / .mozilla > dichotomy? I think the bug starter reported this simply because of the oddity of Firefox unnecesarily creating a ~/.mozilla directory. To be honest it's a rather trivial issue, but at the same time it looks strange and causes confusion (at least I was a bit confused as to why it was there). Like I said, wouldn't a wallpaper patch disabling the creation of .mozilla and changing the profile plugins location to ~/.firefox/plugins be best for 1.7? As Asa said in comment 1, this should have been fixed a long time ago.
(In reply to comment #55) > Like I said, wouldn't a wallpaper patch disabling the creation of .mozilla and > changing the profile plugins location to ~/.firefox/plugins be best for 1.7? Well, it would be a real patch, not a wallpaper patch, but I'm not sure this is the right thing to do. I think that firefox should probably still be looking for plugins in ~/.mozilla/plugins, if that directory exists; hopefully we can avoid creating that directory if it doesn't exist. If we decide that plugins ought to live in ~/.firefox/plugins (I think this is a bad idea), I can add plugin-copying to Ben's profile-migration code with little effort.
(In reply to comment #52) > To answer your question directly, his proposal requires considerably more work > with potentially further reaching effects (like changing xpcom) on the seamonkey > side of things than the new-world apps (from my understanding). If I'm wrong, > then please correct me. No, that's not what I was proposing; perhaps I didn't explain it clearly. Here is what I am proposing: - Leave seamonkey defaults in nsAppFileLocationProvider.cpp alone. - Change the location of the profile and plugin directories for Firefox by changing toolkit/xre/nsXREDirProvider.*, toolkit/xre/nsXULAppAPI.h, browser/app/nsBrowserApp.cpp. The firefox profile root moves to ~/.mozilla/firefox/profiles; the firefox and seamonkey plugin path remains ~/.mozilla/plugins. Same for Thunderbird. So none of these changes affect any code which would ship as part of Seamonkey 1.7. Seamonkey can optionally move to ~/.mozilla/seamonkey/profiles at a later date, but this is not required.
> So none of these changes affect any code which would ship as part of Seamonkey > 1.7. Seamonkey can optionally move to ~/.mozilla/seamonkey/profiles at a later > date, but this is not required. Per comment #46, you're proposing changing the standard for all gecko apps, correct? If so, then as the default example of a gecko app, SeaMonkey would need to change as well. And since 1.7 will be the new stable branch for embeddors and gecko users to build upon, this sort of change should go into 1.7. Otherwise, you're just talking about a one-off change for firefox & thunderbird (& maybe composer/nvu) since anyone who's not building upon toolkit/ isn't going to see those changes. > No, that's not what I was proposing; perhaps I didn't explain it clearly. If we agree that using a ~/.<vendor>/<app> heirarchy is the Right Thing(tm) to do, then why are we *only* doing it for the new world apps?
Re: comment 52: cls, play fair -- you brought up the milestone plan, not me. If you can jerk your knee, but I can't jerk mine, how fair is that? I should keep my knee from jerking, sure -- but you're in a glass house. Put down the stone. bryner and I talked about this bug on IRC quite a bit, and I think you've misread his proposal (ah, there he is in comment 57 trying to clear things up). But you seem to have a bee in your bonnet about "fixing" SeaMonkey not to rely on XPCOM defaults that have been there since before Mozilla 1.0 -- why is that necessary? As a driver, I might not fret about a patch to add a dirprovidr impl to xpfe, so SeaMonkey looks all modern -- but what's the gain? Why is it worth doing, except for aesthetic reasons? We can fix this bug without having to do that much work. I still think you were trying for a "gotcha" against drivers about the milestone plan, and that distorts the engineering here. 1.7, 1.8, whatever -- if we are keeping SeaMonkey on sustaining engineering, we don't necessarily want to make symmetric changes to it and XPCOM. There may even be other XPCOM-based apps that would want the SeaMonkey'ish defaults we've shipped since before 1.0, but which do not use xpfe. Let's see a patch from bryner and then evaluate the engineering trade-offs, independent of schedule. If this bug were only patchable in a way that required 1.8 to be the stable branch, and it were important enough to motivate that, then I'd help move heaven and earth. But I don't believe the technical facts bear out such a tendentious claim. /be
(In reply to comment #58) > > If we agree that using a ~/.<vendor>/<app> heirarchy is the Right Thing(tm) to > do, then why are we *only* doing it for the new world apps? > Because Seamonkey doesn't have the type of migration architecture in place that Firefox has to migrate profiles to the new location; neither myself nor anyone else I'm aware of is willing and able to write that code, and that should not block resolving this for Firefox.
Having said that, cls, if you want to write a migrator for Seamonkey, feel free.
This works on Linux; still need to test on Mac and Windows.
> Re: comment 52: cls, play fair -- you brought up the milestone plan, not me. If > you can jerk your knee, but I can't jerk mine, how fair is that? I should keep > my knee from jerking, sure -- but you're in a glass house. Put down the stone. Oh, good grief. I used an additional 2 word adjective to describe the 1.7 branch and somehow you think that gives you cause to go on a crusade about your milestone plan even though it wasn't even directly referenced. Get a grip. This proposed change is "poorly timed" for going into the seamnonkey tree regardless of your precious milestone plan given that we plan to branch for release later today. > But you seem to have a bee in your bonnet about "fixing" SeaMonkey not to rely > on XPCOM defaults that have been there since before Mozilla 1.0 -- why is that > necessary? What I see is a new "standard" being proposed for the user-profile location of gecko apps and I'm trying to make sure that seamonkey doesn't get left behind (being a gecko app and all & one that I use to boot). I asked a question about which approach bryner would recommend that we take for seamonkey: change the xpcom defaults or have seamonkey implement it's own directory service. Neither is a trivial change afaict which puts it at odds for going into a soon to be released tree or a stable branch. And his recommendation for seamonkey at least seems to be: don't do it. > As a driver, I might not fret about a patch to add a dirprovidr impl > to xpfe, so SeaMonkey looks all modern -- but what's the gain? Why is it worth > doing, except for aesthetic reasons? We can fix this bug without having to do > that much work. Yes, you can fix the bug with the minimal changes that bryner proposes (I think). (If the directory service is still creating ~/.mozilla after the changes then nothing has been solved.) The issue that I keep bringing up has to do with the fact that bryner mentioned a general change to the user-profile locations. If his proposal were to just modify toolkit's impl of nsIDirectoryServiceProvider in order to avoid the bogus directory creation, there'd be nothing to discuss. However, his detailed proposal implements that new directory structure for firefox & thunderbird with a minimal amount of work. For seamonkey and the any other app that wants to follow the proposed new user profile dir layout and doesn't already use toolkit/ or has its own directory service implementation, it's a bit more work but I guess the other apps don't matter at this juncture. > I still think you were trying for a "gotcha" against drivers about the milestone plan, and that distorts the engineering here. Well, you're wrong since I could've told you upfront that I consider the milestone plan a lost cause and I don't believe anything will change that so I wouldn't waste my time (or yours) trying. Let me spell it out: Bryner's proposal seems like A Good Thing(tm) for all gecko apps so I'm trying to make sure that we're at least considering what needs to be done for all gecko apps (Mozilla the platform) (seamonkey in particular) *before* we implement something *right now* for firefox & thunderbird (Mozilla.org's flagship apps) and then forget about the rest. > 1.7, 1.8, whatever -- if we are > keeping SeaMonkey on sustaining engineering, we don't necessarily want to make > symmetric changes to it and XPCOM. There may even be other XPCOM-based apps > that would want the SeaMonkey'ish defaults we've shipped since before 1.0, but > which do not use xpfe. So the answer to the questions I posed in previous commments is that if the collective we were to decide that bryner's proposal was a useful change for seamonkey, we'd have to do it by implementing our own directory service and leaving xpcom alone. That's fine.
Comment on attachment 145916 [details] [diff] [review] implement the vendor/product profile location >+#ifndef XP_MACOSX >+ else if (!strcmp(aProperty, NS_USER_PLUGINS_DIR)) { >+ if (!mVendorDir.IsEmpty()) >+ rv = GetVendorDirectory(getter_AddRefs(localFile)); >+ else >+ rv = GetProductDirectory(getter_AddRefs(localFile)); >+ >+ if (NS_SUCCEEDED(rv)) >+ rv = localFile->AppendNative(NS_LITERAL_CSTRING("plugins")); >+ } >+#endif Umm? Does this mean that firefox plugins are going to be in ~/.mozilla/firefox/plugins? Shouldn't we be sharing plugins between all Mozilla apps? (i.e. use ~/.mozilla/plugins for seamonkey/firefox/whatever)
Firstly, I realized that I never stated why I am worried about multiplying the "plugins" directories: Think of the needs of plugin installers (e.g. Flash). It's much better if we have a single canonical location where all gecko-based apps will look for plugins, instead of one location for seamonkey, another for firefox, and others for embedded apps such as mfcembed/gtkembed. In fact, it would be really good to have a single system-wide location, such as {Common Files}\mozilla.org\plugins (on win32) or /usr/lib/mozilla.org/plugins (on *nixy systems). But that is another bug. The current system described in http://www.mozilla.org/projects/plugins/install-scheme.html is silly. Secondly, about this patch, I think the vendor should be "mozilla.org" instead of "Mozilla": C:\Application Data\mozilla.org\Firefox This would avoid potential conflicts with seamonkey profile paths.
o my. I seem to have spawned quite a fascinating discussion. However, after all this is said and done, would it be feasible to decide once and for all whether or not it is a bug that Firefox creates a directory named ~/.mozilla, and whether or not it is also a bug that Firefox will not read plugins in ~/.firefox/plugins? (I can file a separate bug for that if needed).
(In reply to comment #64) > (From update of attachment 145916 [details] [diff] [review]) > >+#ifndef XP_MACOSX > >+ else if (!strcmp(aProperty, NS_USER_PLUGINS_DIR)) { > >+ if (!mVendorDir.IsEmpty()) > >+ rv = GetVendorDirectory(getter_AddRefs(localFile)); > >+ else > >+ rv = GetProductDirectory(getter_AddRefs(localFile)); > >+ > >+ if (NS_SUCCEEDED(rv)) > >+ rv = localFile->AppendNative(NS_LITERAL_CSTRING("plugins")); > >+ } > >+#endif > > Umm? Does this mean that firefox plugins are going to be in > ~/.mozilla/firefox/plugins? No, that's explicitly what I'm avoiding. GetVendorDirectory() + "/plugins" == "~/.mozilla/plugins".
> Oh, good grief. I used an additional 2 word adjective to describe the 1.7 > branch and somehow you think that gives you cause to go on a crusade about > your milestone plan even though it wasn't even directly referenced. Comment 52 first paragraph ends: "We could go off on a whole separate tangent about the prematureness of the stable branch but that's not exactly being productive (here at least)." A direct reference. Nice try at pretending you're not derailing the bug, but false arguments need to be answered, always. We can take this to a newsgroup any time you like -- you started it, you can end it taking up space in this bug. > Get a grip. Got one, thanks. I'm not sure about your grip, though. You haven't justified your requirement that SeaMonkey be brought up to the state of modularity of the the new apps, instead of counting on old XPCOM defaults that have been there for years, and that probably should be left alone until a major compatibility break such as Mozilla 2.0. > This proposed change is "poorly timed" for going into the seamnonkey tree Why? What's the risk? Are you writing a patch? Have you estimated the size of the patch, its effects on other code, other codes' effects on it? > regardless of your precious milestone plan given that we plan to branch for > release later today. Branches take updates; we kept the 1.0 branch going for a while. Your writing here is all content-free anger. Look, I'll rewrite it from the opposite point of view without adding or removing facts: "This proposed SeaMonkey change [comment 52, second paragraph] is 'poorly timed' for going into the mozilla 1.x tree regardless of your precious SeaMonkey plan given that we plan to branch for release later today." I could add relevant facts about distributors planning to use the 1.7 branch who *do not want* any profile directory structure change for their SeaMonkey-based products, period. > For seamonkey and the any other app that wants to follow the proposed new > user profile dir layout and doesn't already use toolkit/ or has its own > directory service implementation, Why is this important or even beneficial work to do, now or even later, for xpfe-based apps? > it's a bit more work Only a bit, and not a bigger patch than many we'll take on the 1.7 branch, and not risky by comparison either. Any more than patches we took for 1.0 and 1.4 after branching. But (I'm not taking your side, relax ;-) -- why bother? > but I guess the other apps don't matter at this juncture. It matters more that they keep working as they have been. No one, including major distributors who will release SeaMonkey-based products off of the 1.7 branch, wants a profile reorg for it. Except you, for some aesthetic or "consistency" reason that is not a valid engineering consideration without a lot more explanation. Worrying about hypothetical bugs in bryner's patch does not count. I shoot back when shot at, so don't cry about it -- take the heat, or move the kitchen to a newsgroup. Yeah, I'm not happy with the 1.7 branch plan or (more to the point) how it was communicated. But it ain't gonna change, and we ought *not* futz around with SeaMonkey unnecessarily in 1.8 (any 1.8, stable or not). /be
> > it's a bit more work > > Only a bit, and not a bigger patch than many we'll take on the 1.7 branch, and > not risky by comparison either. I left out the unknown and hard to estimate risk that by removing the old defaults from XPCOM, we break some third party that doesn't use xpfe as-is, or at all. But that seems unlikely. Really, I can't see a reason other than aesthetic consistency to make SeaMonkey implement its own dirprovider. And distributors (whether of 1.7 or a stable 1.8 had that been possible) don't want it. cls: I am sorry for getting angry backatcha. Tell me if there's a business case for futzing with SeaMonkey, I'll go to bat. I don't see it here. /be
(In reply to comment #69) > Really, I can't see a reason other than aesthetic consistency to make SeaMonkey > implement its own dirprovider. And distributors (whether of 1.7 or a stable 1.8 > had that been possible) don't want it. I believe that it would be a good thing for seamonkey to implement a dirservice provider and can the XPCOM default one, early in an alpha cycle so that embedders have enough time to react. The appdirserviceprovider in XPCOM makes some terrible assumptions that are just wrong for non-seamomkey apps, and embedders are not likely to notice this wrongness easily. I don't think it would ever be desirable to change the seamonkey default profile location from ~/.mozilla to something else, thus my vote for "mozilla.org" as the new-scheme root.
(In reply to comment #68) > > Oh, good grief. I used an additional 2 word adjective to describe the 1.7 > > branch and somehow you think that gives you cause to go on a crusade about > > your milestone plan even though it wasn't even directly referenced. > > Comment 52 first paragraph ends: "We could go off on a whole separate tangent > about the prematureness of the stable branch but that's not exactly being > productive (here at least)." > > A direct reference. Nice try at pretending you're not derailing the bug, but > false arguments need to be answered, always. Yes, they do. Note that comment #52 comes *after* comment #51 which is where you decided to "shoot back" as you put it, presumably about something as miniscule as using "poorly timed" to describe the 1.7 branch. The decision to go off on the non-productive tangent (which I admittedly did warn about) was yours. > You haven't justified your requirement > that SeaMonkey be brought up to the state of modularity of the the new apps, I explained my reasoning in comment #63 but let me state it again since you missed it. I think the directory structure bryner proposed is a good one for all gecko apps and one that we should encourage apps to use rather than the current defaults. Since SeaMonkey is not only a gecko app provided by Mozilla.org but _the_ reference gecko app (though I could be mistaken on that point), it should implement things in the recommended fashion to provide the good example for other apps. > instead of counting on old XPCOM defaults that have been there for years, and > that probably should be left alone until a major compatibility break such as > Mozilla 2.0. I overlooked the fact that nsIDirectoryService was frozen. > > This proposed change is "poorly timed" for going into the seamnonkey tree > > Why? What's the risk? Are you writing a patch? Have you estimated the size of > the patch, its effects on other code, other codes' effects on it? Because it's a user-visible change and involves non-trivial profile migration issues as bryner pointed out. That seems like the sort of change that you wouldn't want to make at the last minute. > > regardless of your precious milestone plan given that we plan to branch for > > release later today. > > Branches take updates; we kept the 1.0 branch going for a while. Given my personal experience, getting trivial non-user visible build changes into branches has been far more cumbersome than it should be so I would expect non-trival user-visible changes to be exponentially worse. Again, I could be wrong. > Your writing here is all content-free anger. Just because you're overlooking the content doesn't mean that it isn't there. My anger stems from the uncalled for personal attacks when I was trying to contribute to fixing this bug and hash out the possible effects of bryner's proposal. > I could add relevant facts about distributors planning to use the 1.7 branch who > *do not want* any profile directory structure change for their SeaMonkey-based > products, period. That would be helpful but probably unnecessary at this point. > > For seamonkey and the any other app that wants to follow the proposed new > > user profile dir layout and doesn't already use toolkit/ or has its own > > directory service implementation, > > Why is this important or even beneficial work to do, now or even later, for > xpfe-based apps? See above explanation. > No one, including > major distributors who will release SeaMonkey-based products off of the 1.7 > branch, wants a profile reorg for it. Right, which is why I said that this change was poorly timed. But as bryner pointed out, SeaMonkey-based products could implement or not implement the directory service as they choose. I'm not saying that we should screw over business plans that are in place but that at some point, with plenty of notice, we should be able to make the changes that we want rather than just writing everything off as "legacy". > I shoot back when shot at, so don't cry about it So do I but when shooting back, you should make sure that a first shot was even made. > But it ain't gonna change, and we ought > *not* futz around with SeaMonkey unnecessarily in 1.8 (any 1.8, stable or not). Not that it's relevant to this particular bug since it's pretty much decided that the profile change won't happen for seamonkey, but it would be *very* helpful if you could define what unnecessary futzing is in the roadmap or something.
I don't think that "cls, please stop grinding that axe" is a personal attack. Taking too much space in bryner's bug will get me dirty looks tomorrow, but I am not fooling around here, and I don't think cls is either -- we're arguing about things we think matter. But we're irreconcilably opposed, so something has to give. That something is SeaMonkey upkeep and parity with other apps, especially given distributor plans that lack migration code and don't want more risk. There's no good reason to reorg SeaMonkey's profile dir at this time, and some good reasons not to. I don't see that changing. Sustaining, conservative (the roadmap uses these words, I'm paraphrasing) means *leaving code alone*. bsmedberg, I would rather we deprecate the old XPCOM implementation and provide something better than try to put a better implementation in xpfe. Or are you suggesting we move the impl, leaving no default in XPCOM? Either approach seems not quite compatible enough. SeaMonkey is not a good exemplar of how to embed Gecko, if that's what cls means by "_the_ reference gecko app". As a reference for others embedding Gecko, Seamonkey is a mess -- not that that's anyone's fault who worked on it. We had to build a decent app first. The platform and reusable Gecko core came second, and still do for things like Firefox 1.0. We have to walk and chew bubble gum, and we're still learning to chew bubble gum. > it would be *very* helpful if you could define what unnecessary futzing is in > the roadmap or something. It can't be defined generically. Lots of examples won't necessarily help the next time. We want bug fixes, but not UI changes (manage by exception where there is a security hole, or a really awful/unusable UI and someone willing to fix it and own the fix). Significant for this bug: We don't want profile changes unless distributors and third-party tools that know the old layout (which goes way back, not only to Netscape 6 by to 4.x, I think, although of course under a different name) are all ready to resync and migrate. SeaMonkey is not end of life, but it will be some day in the foreseeable future, at the latest by the time there is a Mozilla 2.0, unless volunteers step up to own a port to that world, including tinderbox coverage and thankless (endless) fixing others' breakage. I'm expecting the 1.x world to sustain for years (governments may want it that long), but that's the trunk not to futz with, and it will become a branch not to futz with in a year or so. Sorry my crystal ball isn't any better. /be
fix a compile error on windows, and change Mac to _not_ use a vendor subdirectory (I came to the conclusion that it's inconsistent with the platform on Mac, per documentation on developer.apple.com and looking at what existing apps do). On Windows I think there's a strong precedent for Vendor\Product under Application Data, and it's also something apps are doing on linux (i.e. all GNOME apps keeping settings under .gnome/).
Attachment #145916 - Attachment is obsolete: true
Flags: blocking0.9?
Attachment #146077 - Flags: review?(bsmedberg)
+ing for .9 since we can only do profile data migration once.
Flags: blocking0.9? → blocking0.9+
Mine, I need to land semi-single-profile first.
Assignee: bryner → bsmedberg
Depends on: semi-single-profile
Benjamin, do you want to do this? If so, please changes carefully with various migration paths from 0.8 etc. If you can't do this by 0.9 it probably can't ever happen. The Unix Seamonkey Profile called Firefox doesn't really bother me all that much, since it represents such a tiny proportion of our users.
Attached patch patch (obsolete) — — Splinter Review
Needs testing on OS X and linux, will do so tomorrow.
Assignee: bsmedberg → bugs
Attachment #144442 - Attachment is obsolete: true
Attachment #146077 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Comment on attachment 149743 [details] [diff] [review] patch I'm vaguely worried about this patch if [appdata]/Mozilla doesn't already exist: I think there needs to be additional calls to ensure that both directories exist.
I'll check on profileservice to make sure it creates the right hierarchy, thanks benjamin.
Place Firefox into ~/Library/Application Support/Firefox per Mac convention, rather than ~/Library/Mozilla/Firefox as the first patch does.
Attachment #149743 - Attachment is obsolete: true
Attachment #149801 - Attachment is obsolete: true
Attachment #149803 - Attachment is obsolete: true
Fixed, branch only. Dependent on semi-single profile before can land on the branch.
Whiteboard: fixed-aviary1.0
Comment on attachment 146077 [details] [diff] [review] implement the vendor/product profile location obsolete patch, removing review request
Attachment #146077 - Flags: review?(bsmedberg)
It still reappears. Mac OS X 10.3.4 AVIARY_1_0_20040515_BRANCH build Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; ja-JP; rv:1.7) Gecko/20040701 Firefox/0.9.0+
Flags: blocking-aviary1.0PR?
its fixed on branch already
Flags: blocking-aviary1.0PR?
This is fixed everywhere.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago → 20 years ago
Resolution: --- → FIXED
v. FYI: The needed profile movement for TB is covered by bug 247973.
Status: RESOLVED → VERIFIED
Component: Build Config → General
Product: Firefox → Firefox Build System
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: