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.

Categories

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

enhancement
Not set
normal

Tracking

(Not tracked)

RESOLVED INCOMPLETE

People

(Reporter: avih, Unassigned)

References

()

Details

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 installation. 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: N/A Actual Results: N/a 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: http://forums.mozillazine.org/viewtopic.php?t=15015 http://forums.mozillazine.org/viewtopic.php?t=14627 http://forums.mozillazine.org/viewtopic.php?t=14940 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. so: 1. create your sandbox directory (i.e. d:\sandbox\px-0.6). we'll consider it as <sandbox>. 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 (mozilla/mozillafirebird). 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>\run.bat <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 versions. 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. cheers avih
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). avih
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 (http://kmeleon.sourceforge.net/) 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 https://sourceforge.net/project/showfiles.php?group_id=14285 (I tested it with v0.8.2) -install (to $kmdir) -run and configure what you want. All prefs are in kmdir\Profiles\default\xxxxxx.slt -copy the $kmdir\Profiles\default\xxxxxx.slt\Pref.js to $kmdir\defaults\pref\Pref.js -Copy the: $kmdir\Profiles\default\xxxxxx.slt\macro.cfg $kmdir\Profiles\default\xxxxxx.slt\menu.cfg $kmdir\Profiles\default\xxxxxx.slt\accel.cfg files to $kmdir\ -delete the two files $kmdir\components\profile.dll $kmdir\components\profile.xpt -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("kmeleon.plugins.fullscreen.auto", 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: http://theopencd.sunsite.dk/forum/viewtopic.php?t=357&postdays=0&postorder=asc&start=0 K-Meleon home page: http://kmeleon.sourceforge.net/ K-Meleon command line/reference: http://kmeleon.sourceforge.net/manual/reference.html 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 crash. explanation: http://www.hlm.inc.ru/ software: http://www.rekenwonder.com/linkmagic.htm 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 server.
>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: %SystemRoot% %windr% %temp% %USERPROFILE% I've been searching microsoft.com, but haven't found it yet.
%APPDATA% 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 http://bugzilla.mozilla.org/show_bug.cgi?id=74085 17048 - Roaming access - keep bookmarks/cookies/history/etc in a central repository http://bugzilla.mozilla.org/show_bug.cgi?id=17048 31732 - Make Deployment of Roaming Profiles Easier in LAN/WAN Environments http://bugzilla.mozilla.org/show_bug.cgi?id=31732 Firefox on a USB Drive http://www.texturizer.net/firefox/tips.html#oth_usb http://firefox.wlkr.net/fb101.htm http://markpasc.org/weblog/2003/08/26_firebird_from_a_zip_disk.html http://forums.mozillazine.org/viewtopic.php?t=48597 Run Firefox in RAM partition (tutorial) http://forums.mozillazine.org/viewtopic.php?t=55195 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 http://forums.mozillazine.org/viewtopic.php?t=54104
>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: %SystemRoot% %windr% %temp% %USERPROFILE% %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: http://www.thunderbird-mail.de/downloads/exten.php http://downloads.us-east3.mozdev.org/gtl/other/usblauncher/ThunderbirdUsbLauncher.zip the documentation is german but you should have little problems.
*** Bug 239103 has been marked as a duplicate of this bug. ***
Per http://forums.mozillazine.org/viewtopic.php?t=80844&start=15 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 http://forums.mozillazine.org/viewtopic.php?t=80844&start=15 > 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: http://forums.mozillazine.org/viewtopic.php?t=98699&highlight= and this one for workaround: http://forums.mozillazine.org/viewtopic.php?t=81759&highlight=
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
Status: NEW → RESOLVED
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.