Closed Bug 211628 Opened 21 years ago Closed 15 years ago

Need a method to run an entire GRE + profile + Application encapsulated (i.e. from a USB drive) without interfering with the host.


(Core Graveyard :: Embedding: GRE Core, enhancement)

Not set


(Not tracked)



(Reporter: avih, Unassigned)




User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624

the need for an entire GRE based environment in a true sandbox is important in 3
scenarios at least imho:

1. if a user wants to run from a removable drive without interfering with the
host computer's settings/GRE/etc. i.e. from a USB drive, from a removable HD,
etc, while still keeping the full functionality of the environment. i.e.
installing extensions, using bookmarks, profiles, etc.

2.when testing applications/extensions it's important to test on different
browsers/versions for compatibility. it's importent that these environment don't
mix with eachother or with the host primary installation.

3. when someone wants to build a GRE based application, tied to a specific GRE
version, possibly while reusing parts of another application (i.e. mozilla),
with a specific version as well, again, without interfeering with an existing

i would LOVE to be able to run my entire mozilla /firebird/thunderbird from a
usb drive that i can take with me. that would be absolutely wonderfull imho.

a solution i've tried so far, which does seems to offer the functionality i need
is to modify the environment variables (user profile, application data/etc) to
point to a specific directory before running the application. it somehow seems
to work, but ppl told me i'm missing stuff, and there's more than that.

would it be possible?

Reproducible: Always

Steps to Reproduce:
Actual Results:  

Expected Results:  
mozilla runs in an true sandbox
he requested it to assigned to him.
Well, if you have a zipped build instead of an installer build, you don't need
to worry about remote GRE. What would be nice instead of just -P <name of
profile> is a --profile-dir <path_to_profile> command-line option.

Also, although you really don't mention it in this bug, but we talked on IRC...
profiles contain absolute paths (to the mail store, etc) which shouldn't really
be necessary. If you mount your USB drive in the same place on each computer,
that's not much a problem, but most computers don't work like that.
Severity: blocker → normal
1st, this topic seems to be bothering other people as well on the forums. here
are 3 threads that are currently active about this same issue:

as i said on my 1st post (=bug report) i've managed the task by changing
environment variables before running the actual exe file. On winXP, by default,
the %USERPROFILE% var points to c:\documents and settings\<userName> . %APPDATA%
points by default to c:\documents and settings\<userName>\Application Data

both these vars have to be set in order to operate correctly before running the
exe file.


1. create your sandbox directory (i.e. d:\sandbox\px-0.6). we'll consider it as
2. inside it, create a folder named "Application Data" the name must be exact.
3. in your sandbox directory, put the bin directory of the application
4. put this batch file inside your sandbox dir as well (change myAppName to your
actual executable name, and myRoothPath to your root sandbox dir).
you get this:

<sandbox>\Application Data (should be created empty prior to running the batch file)
<sandbox>\bin (this is the actual directory of the application.

here's my (winXP) batch file. i'm not sure how it will work on other windows

rem directory 'Application Data' MUST be created prior to running this file.
rem not creating the 'Application Data' will result in c:\windows\phoenix and
c:\windows\mozilla created
rem the name 'Application Data' MUST NOT be changed. it's expected exactly with
this name.

set myAppName=phoenix.exe
set myRootPath=D:\tmp-extract\sandbox\px-04-mar

set USERPROFILE=%myRootPath%
set APPDATA=%USERPROFILE%\Application Data
start %USERPROFILE%\bin\%myAppName% %1 %2 %3

hope it helps.
just a short note.
with the above settings, a profile will be created the 1st time the batch file
is run.

- it's possible to automatically create 'Application Data' if it doesn't exist
already (add this to the batch file: 
if not exist "Application Data" mkdir "Application Data"

- it's possible to automatically run the exe file without setting the actual exe
name for netscape/mozilla/phoenix/mozillafirebird, thus eliminating the need for
setting myAppName. replace the last line of the prev batch file with these:

if exist "bin\phoenix.exe" start %USERPROFILE%\bin\phoenix.exe %1 %2 %3
if exist "bin\mozilla.exe" start %USERPROFILE%\bin\mozilla.exe %1 %2 %3
if exist "bin\mozillafirebird.exe" start %USERPROFILE%\bin\mozillafirebird.exe
%1 %2 %3

- it's possible to identify the current directory, and thus eliminating the need
to set up myRootPath. it's not trivial, and it requires for batch file tricks,
or external utilities (i.e. pwd.exe), but it IS possible.

with these settings, each sandbox dir configured as above will contain it's own
exe and profile, and you'll even be able to run 2 instances of the same
application simultaneously (i.e. moz-fb 0.6 and moz-fb 2003-06-29 side by side).

Changing some stuff (it's an enhancement, this should be all platforms...)

I agree, that this is a great idea.  IMHO Mozilla apps should first check for a
"profiles.txt" file in the applications own directory (thunderbird directory for
thunderbird, mozilla directory for mozilla... etc.).  That file, in plain text,
would specify where to find the profiles.

If the file is not found, it does the current method of locating profiles.

If found, it looks in the defined location for a profile.

This would allow anyone to to modify the profile parameter with ease, just with
a 1 line text file.

I'm not a fan of a build parameter, because then anyone who wants to run it off
a USB drive needs to compile it themselves.

By putting the file in the apps directory, it's easy to find, and lets each
application do their own.

That would be a nice simple solution to provide the functionality without problems.
Severity: normal → enhancement
OS: Windows XP → All
Hardware: PC → All
But what about CD? The idea is to make a presentation site-style CD with 
preinstalled and preconfigured F07.

F07 use profile folder for cashed data. 
And about last method (profile.txt)... FO7 write profile data already to 
C:\windows\Application data\Phoenix\profiles.dat . Creating new profile-user 
don't take effect to any file in program directory.
I was just able to run K-Meleon from a CD!!!

K-Meleon is a Mozilla based browser (

This means:
it doesn't write anything to the HD
it uses prefs you can set

I don't know how it can be adapt for Mozilla/Firebird, but we are getting closer!

Heres what you'll have to do:
-download k-meleon from (I tested it with v0.8.2)
-install (to $kmdir)
-run and configure what you want. All prefs are in
-copy the $kmdir\Profiles\default\xxxxxx.slt\Pref.js to $kmdir\defaults\pref\Pref.js
-Copy the:
files to $kmdir\
-delete the two files
-remove unwanted plugins from $kmdir\kplugins
-add to $kmdir\defaults\pref\Pref.js your plugin config. Exemple:
user_pref("kmeleon.plugins.bookmarks.load", false);
user_pref("kmeleon.plugins.favorites.load", false);
user_pref("", true);
user_pref("kmeleon.plugins.fullscreen.hide_rebar", true);
user_pref("kmeleon.plugins.fullscreen.hide_statusbar", true);
user_pref("kmeleon.plugins.fullscreen.load", true);
user_pref("kmeleon.plugins.history.load", false);
user_pref("kmeleon.plugins.hotlist.load", false);
user_pref("kmeleon.plugins.layers.load", false);
user_pref("kmeleon.plugins.macros.load", false);
user_pref("kmeleon.plugins.bmpmenu.load", false);
user_pref("kmeleon.plugins.external.load", false);
user_pref("kmeleon.plugins.gestures.load", false);
user_pref("kmeleon.plugins.rebarmenu.load", false);
user_pref("kmeleon.plugins.toolbars.load", true);
This will only load the plugins you want.

I think it is that...
You can find more info on this thread:
K-Meleon home page:
K-Meleon command line/reference:

good luck :)
I forgot one thing, you'll have to delete the
$kmdir\Profiles folder :)
Or else KM will use it...
*** Bug 226540 has been marked as a duplicate of this bug. ***
I tried the above batch file on my Win2k machine and it worked (somewhat). 

The browser works as normal under the above setup for the most part, but it
causes the "Save Link to Disk" option to stop working.  When I select that
option on a link it simply returns me back to the browser without saving the file.  
This may be quite trivial, but there is a getaround in forcing Firebird on a
single partition other than C: on NTFS systems by using the "hard link" feature
of NTFS.
This does not, I think, help in forcing FB on a CD or USB dongle, at least not
without first executing a bat to create the link and again disabling it after
closing down FB. I do not know what side effects this would have in case of a
This method may have consequences, but I got FB 0.7 with many extensions working
 flawlessly from d: alone by creating a dummy path D:\documents and
settings\default user\application data\phoenix\ thus fooling XP (using the hard
link) to think that this path actually resides on C:\.
In my case the files pluginreg.dat and registry.dat are the only files, that
must exist at the end of that path. Locations of other profile-files and dirs
and prog files and dirs are at the users discretion.
I too would love to have a .txt file, where I could define the whereabouts of FB
fikes, just as Robert suggests in #5.
I'm assuming this is probably futile for the time being, but what about the
various registry keys it creates, such as HKLM\Software\Mozilla?
Adding dependency on bug 157662 and bug 150453
Depends on: 150453, 157662
*** Bug 234418 has been marked as a duplicate of this bug. ***
The above mentioned solution with a batch file does only work as long as you use
Windows versions with the same language. If you use it with a german Windows
version Mozilla will not look for its registry.dat in "Application Data" but in
"Anwendungsdaten". I assume that other Windows language versions also have their
own convention.
The only satisfying solution that comes to my mind would be a config file in the
mozilla directory that keeps the path (also relative paths) to the profile.
I agree, using a file in the Mozilla directory is the best approach.  That way,
the user can tweak the file to point as necessary. 

Could be pointing to a USB drive, another hard drive, or perhaps in the future a
>If you use it with a german Windows version Mozilla will not look for its 
> registry.dat in "Application Data" but in "Anwendungsdaten". 

I'd imagine that there is an environment variable you can reference similar to: 

I've been searching, but haven't found it yet.

But that is not available on Win9x.  
Seems like a very old issue I've been tracking... do these bugs relate?
74085  - Disk cache directory should default to local directory
17048  - Roaming access - keep bookmarks/cookies/history/etc in a central repository
31732  - Make Deployment of Roaming Profiles Easier in LAN/WAN Environments

Firefox on a USB Drive
Run Firefox in RAM partition (tutorial) 

I'm trying to keep this up2date as improvements in Managing
Mobile Profiles appear on the scene... -HTH wildman

Mozilla Profile Migration & FAQ - Mobile Profiles
>If you use it with a german Windows version Mozilla will not look for its 
> registry.dat in "Application Data" but in "Anwendungsdaten". 

I'd imagine that there is an environment variable you can reference similar to: 

%APPDATA% is the thing you were looking for. that's correct. but this variable
holds the pathname "Anwendungsdaten" in the german windows xp version. hence it
will not find the profile if you created it on a english speaking windows xp.
There exists a tool that allows you to run Thunderbird from any storage device
without leaving a footprint on your systems harddisc or windows folder.
Unfortunately it does no seem to work with mozilla as well.

get it at:

the documentation is german but you should have little problems.
*** Bug 239103 has been marked as a duplicate of this bug. ***
firefox now has an option to specify path to profile, as in
firefox.exe -Profile "path/to/profile"

So one could create the profile folder as a subdirectory in firefox install
folder, and let it run off the USB key.

There is still a questionmark over whether information inside the profile
contains some absolute profile path information.

> firefox now has an option to specify path to profile, as in
> firefox.exe -Profile "path/to/profile"

Yes, I added this flag specifically so that people could ship firefox on a
CD/USB and have readonly profiles with the app.

> There is still a questionmark over whether information inside the profile
> contains some absolute profile path information.

As far as I know, firefox profiles are now completely clean of absolute path
information. If you find otherwise, please let me know ASAP.
> Per
> firefox now has an option to specify path to profile, as in
> firefox.exe -Profile "path/to/profile"

Will the work for -Profile be inherited by Thunderbird, or is there a similar
bug elsewhere?  A quick search through Thunderbird bugs for "profile" returned
nothing promising after a quick inspection.

On the other hand, after recently configuring Thunderbird to share mail with my
Windows installation, I realize there are plenty of hardcoded paths in the
Thunderbird profile that would need to be fixed.  Perhaps even if the new work
*is* inherited a new bug should be filed.
> Will the work for -Profile be inherited by Thunderbird

Yes, it is part of the core toolkit that all the new-style apps share.

> On the other hand, after recently configuring Thunderbird to share mail with my
> Windows installation, I realize there are plenty of hardcoded paths in the

Thunderbird may indeed have absolute paths that are not fixed yet. Please search
for bugs on these paths, and file new bugs as appropriate. (cc me on these, also).
Since FF/TB supports the new -Profile switch, it would be nice that it would use only relative paths also.
Look at this post:
and this one for workaround:
For those of you trying this with the Mozilla suite, you can pass "-greLocal" as
an argument to the installer to put all the GRE files in the mozilla bin
directory instead of using a shared GRE. Doesn't help with the profile issues,
but since the bug summary still includes "GRE" I thought I'd mention it
(windows-only issue).
Blocks: majorbugs
No longer blocks: majorbugs
mass reassigning to nobody.
Assignee: dougt → nobody
QA Contact: ashshbhatt → gre
closing useless metabug
Closed: 15 years ago
Resolution: --- → INCOMPLETE
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.