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
(deleted), 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"
--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) (deleted) — — 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) (deleted) — — 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) (deleted) — — 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.
Attached patch implement the vendor/product profile location (obsolete) (deleted) — — Splinter Review 
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
Attached patch implement the vendor/product profile location (obsolete) (deleted) — — Splinter Review 
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) (deleted) — — 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.
Attached patch some additional changes from my Mac... (obsolete) (deleted) — — Splinter Review 
Place Firefox into ~/Library/Application Support/Firefox per Mac convention,
rather than ~/Library/Mozilla/Firefox as the first patch does.
Attached patch and some changes for linux (obsolete) (deleted) — — Splinter Review 

    
    

    
  

      
      
      
      

        Attached patch
          
          
        all patches rolled up (deleted)
        — 
          — Splinter Review
      

    


  

        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: