298784 - Remove --with-user-appdir switch

Status: NEW

(Firefox Build System :: General, defect)

Description

[Jonathan Jara-Almonte]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.7) Gecko/20050414 Firefox/1.0.3
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.7) Gecko/20050414 Firefox/1.0+

When compiling firefox, the --with-user-appdir flag claims to set the folder in
which user preferances are stored, however this is not the case. Firefox always
defaults to ~/.mozilla, as it is hardcoded into firefox.

Reproducible: Always

Steps to Reproduce:
1.compile using --with-user-appdir=.foobar
2.run firefox
3.

Actual Results:  
File ~/.mozilla created and used to store profiles and preferance information.

Expected Results:  
File ~/.foobar should have been created and used to store this information.

Attaching a patch that I made to fix this in the CVS code.

Comment 1

[Jonathan Jara-Almonte]

Attachment: Patch based on CVS code; makes firefox respect MOZ_APP_DIR, and thus --with-user-appdir

Comment 2

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 3

[Gervase Markham [:gerv]]

This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.

Comment 4

[Andreas Lange]

Bug with patch awaiting review should not be auto expired.

Comment 5

[Brian Ryner (not reading)]

Comment on attachment 187307 [details] [diff] [review]
Patch based on CVS code; makes firefox respect MOZ_APP_DIR, and thus --with-user-appdir

This isn't right, it will force any XUL app into ~/.mozilla regardless of the gAppData->vendor setting.

For future patches, bsmedberg would probably be a better reviewer.

Comment 6

[Philip Withnall (unavailable)]

*** Bug 332073 has been marked as a duplicate of this bug. ***

Comment 7

[Holger Mense]

I can confirm this bug for Firefox 2.0.0.l.

Comment 8

[Rich]

I can confirm it for Firefox 2.0.0.4

There is more wrong then just the method that was patched, as well.  There are several places in Firefox which calculate a location for the user-appdir, and each uses it's own patented method.

I would submit a patch, but I am unable to glean what the desired behavior might be.

I have found the following, though liberal grepping ...
  browser/app/mozilla.in (in the finished product) sets MOZ_USER_DIR, but 
    does not
    export it.  For my experimentation, I'm going to make the value absolute,
    and then export it.  Then I can (consistantly) use getenv/PR_GetEnv in
    order to access it from the places I will mention below. (except the
    Makefiles, which also have problems with this)
    it does export a version called MOZ_PIS_USER_DIR, which takes it's value
    from MOZ_USER_DIR for the init scripts.

  toolkit/xre/nsXREDirProvider.cpp  nsXREDirProvider::GetUserDataDirectory
    This is doing some funky magic by build a value from the user's home
    directory, and some mysterious vendor and product strings, which may or
    may not be related to the --user-appdir configure option

    It also creates the #define DEFAULT_PRODUCT_DIR, which for windows or
    macos it sets to the literal string "Mozilla".
  
  browser/components/migration/src/nsDogbertProfileMigrator.cpp
    I'm not sure if this is intentional, but this used the hard coded string
    "/.netscape".  It appears to be doing some sort of migration voodoo, so
    so this might not be a problem.

  
  
Makefiles:
  mozilla/browser/app/Makefile.in
    uses sed to replace the string %MOZ_USER_DIR% with the literal 
    .mozilla/firefox this does not respond to --user-appdir.
     
    I would suggest changing the literal string in the sed 
    command to the string @MOZ_USER_DIR@, so that config.status will 
    fill in the value passed to configure when Makefile.in is transformed
    into Makefile
  

  mozilla/xpfe/bootstrap/Makefile.in
    This does the same thing, but uses the string ".mozilla" instead of
    ".mozilla/firefox".


  mozilla/browser/components/migration/src/nsSeamonkeyProfileMigrator.cpp
    This has the naked string ".mozilla" embedded in the c++, which it
    then adds to the seamonkey registry.  I am not sure where it goes from
    there, or if it's related at all.  It might be a Coincidental Constant.

  
Are there any pointers that might indicate what the expected behavior might be?

Comment 9

[Jiri TRAVNICEK [:JITR]]

Per bug #332073, comment #1 the `--with-user-appdir' option to `configure' is not supported.

If so, that would make this bug invalid (and the option in question had better be removed -- as the referenced comment also suggests).

Comment 10

[Jiri TRAVNICEK [:JITR]]

(In reply to comment #9)

> Per bug #332073, comment #1 the `--with-user-appdir' option to `configure' is
> not supported.

Or, per bug #270365, comment #1 it's not supported for products other than SeaMonkey? (Sorry, didn't read it until now...) There are other bugs which suggest the same (e. g. bug #58327), so I guess this is the case.

Therefore, I suggest mentioning this fact in the build docs or adding a short notice into the `configure' built-in help message (which is shown using `./configure --help'). I guess I can easily provide a patch for the latter if interested. :-)

Comment 13

[Nick]

Why can't we fix --with-user-appdir so it works correctly? Is there another way to change the profile directory if this option doesn't work? ie. When creating an unofficial/re-branded build, what is the correct way to avoid placing it in the ~/.mozilla folder?

Comment 14

[errge]

Today I figured out the other locations in the source code which need to be taken care of.

I can't contribute a proper patch now, but this research may help others to fix --with-user-appdir:

> diff --git a/media/webrtc/trunk/webrtc/base/proxydetect.cc b/media/webrtc/trunk/webrtc/base/proxydetect.cc
> index 83596b56699e..529d72b94db7 100644
> --- a/media/webrtc/trunk/webrtc/base/proxydetect.cc
> +++ b/media/webrtc/trunk/webrtc/base/proxydetect.cc
> @@ -404,7 +404,7 @@ bool GetFirefoxProfilePath(Pathname* path) {
>      return false;
>    }
>    path->SetFolder(std::string(user_home));
> -  path->AppendFolder(".mozilla");
> +  path->AppendFolder(".gregzilla");
>    path->AppendFolder("firefox");
>  #endif  // WEBRTC_WIN
>    return true;
> diff --git a/toolkit/xre/nsXREDirProvider.cpp b/toolkit/xre/nsXREDirProvider.cpp
> index 62da8de9b0c2..27b279b4cfe7 100644
> --- a/toolkit/xre/nsXREDirProvider.cpp
> +++ b/toolkit/xre/nsXREDirProvider.cpp
> @@ -424,7 +424,7 @@ nsXREDirProvider::GetFile(const char* aProperty, bool* aPersistent,
>  #if defined(XP_MACOSX)
>        rv = localDir->AppendNative(NS_LITERAL_CSTRING("Mozilla"));
>  #else
> -      rv = localDir->AppendNative(NS_LITERAL_CSTRING(".mozilla"));
> +      rv = localDir->AppendNative(NS_LITERAL_CSTRING(".gregzilla"));
>  #endif
>      }
>      if (NS_SUCCEEDED(rv)) {
> @@ -1744,7 +1744,7 @@ nsXREDirProvider::AppendSysUserExtensionPath(nsIFile* aFile)
>  
>  #elif defined(XP_UNIX)
>  
> -  static const char* const sXR = ".mozilla";
> +  static const char* const sXR = ".gregzilla";
>    rv = aFile->AppendNative(nsDependentCString(sXR));
>    NS_ENSURE_SUCCESS(rv, rv);
>  
> @@ -1777,7 +1777,7 @@ nsXREDirProvider::AppendSysUserExtensionsDevPath(nsIFile* aFile)
>  
>  #elif defined(XP_UNIX)
>  
> -  static const char* const sXR = ".mozilla";
> +  static const char* const sXR = ".gregzilla";
>    rv = aFile->AppendNative(nsDependentCString(sXR));
>    NS_ENSURE_SUCCESS(rv, rv);
>  
> @@ -1866,7 +1866,7 @@ nsXREDirProvider::AppendProfilePath(nsIFile* aFile, bool aLocal)
>    }
>    else {
>      if (!vendor.IsEmpty()) {
> -      folder.Append(vendor);
> +      folder.Append("gregzilla");
>        ToLowerCase(folder);
>  
>        rv = aFile->AppendNative(folder);

Comment 15

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S3. However, the bug has 3 duplicates.
:ahochheiden, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 16

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.