283779 - Enhancement: Add a flag to provide an alternate 'Application Data' directory

Status: NEW

(Toolkit :: Startup and Profile System, enhancement, P3)

Description

[ZC]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041223 Firefox/1.0 (Firefox-Comm-Ed-mmoy-1.0-P3W-X9)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041223 Firefox/1.0 (Firefox-Comm-Ed-mmoy-1.0-P3W-X9)

Request For Enhancement: Under Windows XP, Firefox stores files (profiles.ini &
pluginreg.dat) in the Users 'Application Data' directory, usually 'C:\Documents
and Settings\<user>\Application Data\Mozilla\Firefox'. This causes problem for
users who wish to customize this, usually for portability (USB key or WinPE (or
BartPE)).

I propose that an environment variable check be added to provide a custom value
for this directory (similar to MOZ_PLUGIN_PATH for the Plugin directory). The
variable would probably be called MOZ_APPDATA_PATH and would be set by the user
before starting Firefox.

I do NOT have build resources here, but I MAY be able to provide a patch for
this soon.

Reproducible: Didn't try

Steps to Reproduce:
At a command prompt:
SET MOZ_APPDATA_PATH=<custom>
start firefox.exe
Actual Results:  
Firefox started and used the profiles.ini, etc at
C:\Documents and Settings\<user>\Application Data\Mozilla\Firefox

Expected Results:  
Firefox started and used the profiles.ini, etc at <custom>

Comment 1

[Darin Fisher]

have you tried using the -profile command line flag to firefox?

  "firefox -profile e:\foo\bar"

be sure to create the directory "e:\foo\bar" before running firefox in this way.
 note: the only problem i've found with this approach is that it does not invoke
the profile migration code, and moreover it also does not seem to copy over
default bookmarks and other such files.  but, otherwise it works great for me.

Comment 2

[ZC]

Attachment: Proposed patch, v1

Here's a proposed patch. Beware, I have NO build tools on this machine, so this
was created by hand.

Comment 3

[ZC]

(In reply to comment #1)
> have you tried using the -profile command line flag to firefox?
> 
>   "firefox -profile e:\foo\bar"
> 
> be sure to create the directory "e:\foo\bar" before running firefox in this way.
>  note: the only problem i've found with this approach is that it does not invoke
> the profile migration code, and moreover it also does not seem to copy over
> default bookmarks and other such files.  but, otherwise it works great for me.



Even when specifying a profile, the AppData folder gets created and at least
partially used (for pluginreg.dat, at the very least). If this can be
user-specified by environment variable, it can be used, for example, on a BartPE
CD, with Firefox on the CD, but AppData (and profiles) on a RAMDisk.


ZC

Comment 4

[Nick Bebout]

I'm confirming this, even though I'm not sure what the difference is between
this and -profile, except that bug 272983 would have to be fixed to make the
profile entirely located in the specified directory.

Comment 5

[Benjamin Smedberg]

I am very unlikely to support an environment variable for this, but a
command-line flag or a file sitting next to the firefox executable might be a
useful feature for USB sticks and standalone CDs.

Comment 6

[John T. Haller (email is bugzilla2@)]

Unfortunately, it looks like Firefox also hard codes the application directory.
 Specifically, it appears to use %USERPROFILE%\Application Data instead of using
the %APPDATA% environment variable.  So, even if you wrap Firefox in a launcher
that passes in a different APPDATA value, Firefox will ignore it.

I noticed this while working on Portable Firefox and was sure it had already
been filed as a bug.  If you'd like to test this without messing with your own
environment variables, try using this launcher:
http://forums.mozillazine.org/viewtopic.php?p=1777005#1777005

Comment 7

[Benjamin Smedberg]

>  Specifically, it appears to use %USERPROFILE%\Application Data instead of using
> the %APPDATA% environment variable.  So, even if you wrap Firefox in a launcher
> that passes in a different APPDATA value, Firefox will ignore it.

We use the correct Windows system call to find the Appdata directory:
http://lxr.mozilla.org/mozilla/source/toolkit/xre/nsXREDirProvider.cpp#740

Comment 8

[Christian :Biesinger (don't email me, ping me on IRC)]

I believe that the appdata value is stored in a registry key.

Comment 9

[John T. Haller (email is bugzilla2@)]

(In reply to comment #8)
> I believe that the appdata value is stored in a registry key.

That may explain it.  If Firefox has ever been run on a machine, it will ignore
a change in the %APPDATA% variable.  Either way, the end result is that it will
only respond to a different %USERPROFILE% environment variable in my tests with
Portable Firefox, which will allow the pluginregistry to be on the key, but
breaks the Desktop and My Documents sections within file dialogs.

Comment 10

[John T. Haller (email is bugzilla2@)]

(In reply to comment #9)
> That may explain it.  If Firefox has ever been run on a machine, it will ignore
> a change in the %APPDATA% variable.  Either way, the end result is that it will
> only respond to a different %USERPROFILE% environment variable in my tests with
> Portable Firefox, which will allow the pluginregistry to be on the key, but
> breaks the Desktop and My Documents sections within file dialogs.

Actually, that doesn't explain it.  If you try out the launcher I linked to and
set a different userprofile environment variable (but leave appdata completely
untouched), Firefox will actually create an Application Data directory within
the USERPROFILE directory and drop the pluginregistry there.  This doesn't seem
to be a behavior of Windows as reversing the variables (APPDATA set, USERPROFILE
standard) causes the pluginregistry to be placed in Documents and Settings. 
Perhaps it is hard coded within the pluginregistry section.

Comment 11

[James Ross]

%USERPROFILE% affects it, but %APPDATA% does not, because it is stored in the
registry as a REG_EXPAND_SZ (variable replacement string) as:

AppData: %USERPROFILE%\Application Data

This means that the application data folder applications get - along with the
other profile folders - do depend on %USERPROFILE% (the Win32 API call will just
extract the right value from the registry, at least for these profile folders).
%APPDATA% is, I think, set by Explorer when logging in, and is only a
convenience for scripts and such.

This of course doesn't really help if you want to control explicitly where Moz
or FF want to put their data, but should explain the behaviour you're seeing.

Comment 12

[John T. Haller (email is bugzilla2@)]

(In reply to comment #11)
> %APPDATA% is, I think, set by Explorer when logging in, and is only a
> convenience for scripts and such.
> 
> This of course doesn't really help if you want to control explicitly where Moz
> or FF want to put their data, but should explain the behaviour you're seeing.

Ah, thanks James.  That makes sense.  But, yes, it is unfortunate.  I was hoping
the %APPDATA% environment variable would be the perfect workaround to this issue.

Comment 14

[Dave Townsend [:mossop]]

This is actually important for all platforms for the testing case where we should avoid Firefox writing to the user's real settings directories during testing. See bug 1539868 comment 0.