There is a very strange behaviour of Portable Firefox 2 concerning file opening dialogs: they don't appear. First I thought it is a Firefox 2 issue because Portable Firefox 1.5 does not offer this bug. But let me first describe what I have tested and which software I use:
The FirefoxPortable.exe has version 1.2.1.1
Firefox has version 2.x (version doesn't matter, because it isn't a Firefox issue)
OS is Windows 2000 SP4
All the Software copied to a Memorex 1GB Traveldrive endowed with NTFS.
1. Running FirefoxPortable.exe with the FirefoxPortable.ini
[FirefoxPortable]
FirefoxDirectory=APP\firefox
ProfileDirectory=..\..\Einstellungen\Firefox\Test (I started with a empty folder \Test and generated a brand
PluginsDirectory=plugins
UserProfileDirectory=..\..\Einstellungen\Firefox\Test
ProfileDirectory
UserProfileDirectory=
AdditionalParameters=
AllowMultipleInstances=false
SkipChromeFix=false
SkipCompregFix=false
WaitForFirefox=false
FirefoxExecutable=firefox.exe
DisableSplashScreen=false
then initiating a file dialog with File->Open File fails. No error message, no file selection box, nothing!
2. Next test: I put the USB stick to a Windows XP System. No bug, no failure, the file selection box appears without delay.
3. Next test: I put the stick back to my W2000 PC. Now I start "firefox.exe -p" forcing firefox to display the profile dialog. I order firefox to use the profile I selected in the FirefoxPortable.ini file. I start the file opening dialog. No bug, no failure, the file selection box appears without delay as I experienced with the XP system. This is the reason why I assume that the failure is a FirefoxPortable issue rather than a firefox issue.
But I am wondering wether this is phenomenon related to my notebook or is it possible to verify it in common. I have checked the windows event protocols for eventual errors after executing a file dialog. I found no events. I have no idea yet how to fix the problem. The only hint I can give: If I order firefox to use a special folder (for example: "Desktop") by default to store downloaded files then I get a new folder "Desktop" in my profile directory (i.e. ..\..\Einstellungen\Firefox\Test\Desktop) and I find all my downloaded files in this folder. The files don't appear on the Windows desktop as you would guess probably.
I'd appreciate any good ideas. May be the problem is a part of other problems as long as it is not fairly recogneized.
Visit the Community page
Join our forums
Subscribe to our email newsletter
Subscribe with RSS
Follow us on Facebook
Follow us on LinkedIn
Follow us on Twitter
Follow us on Mastodon
Follow us on BlueSky
Did you try it on that machine with the default profile without an INI? If so, then it's either your profile that's messed up or it's something with your long path with the up directory portions (which may work but are not supported).
Sometimes, the impossible can become possible, if you're awesome!
So I followed your suggestion and startet FirefoxPortable.exe without an ini file. Therefore I forced Firefox Portable to use the Standard profile in the Data Folder. The described bug is gone. So far, so good.
Nevertheless I didn't implemented the NTFS filesystem and the separate profile folders not just for fun. Because FirefoxPortable is for portable use I made painful experience with virus infected systems in the past. To stop virusus to write my program files I separated the data and program file paths allowing write access only to the data region. This worked fine with PortableFirefox 1.5.x. But now for some reason there is a problem with the profile paths in the ini file. The profile is correctly loaded (I can see all my bookmarks, cookies etc.) only the download directory seems to have screwed up paths when firefox is started with FirefoxPortable using a different profile path set by an ini file. As I told before the same firefox profile has no malfunction when it is selected by firefox directly. I know that the solution I found to block viruses is snake oil if a virus programmer recogneized what I did. But for the moment it is no need to find more sophisticated solutions because they don't know.
Firefox requires write access to both its data and its binary directories. It won't work otherwise.
Sometimes, the impossible can become possible, if you're awesome!
1. FirefoxPortable 2 works fine with separateted rights for both directories. (naturally updates eventually won't). There is only the "file open" bug. This bug happens on the machine which has actually write access to all directories.
2. There is no problem with all foreign XP machines. I just typing this answer on such a machine, proving that firefox need write access only to the profile folder.
3. There was never a bug with (portable) firefox 1.5.x
It doesn't matter if it's logical or not. The official word from Mozilla has always been that both the Firefox binary directory and the profile directory REQUIRE write access. In the Portable version, the whole thing requires it. You're welcome to muck about with other things, but it's not supported and it may cause odd issues to crop up.
Sometimes, the impossible can become possible, if you're awesome!
The good news for all FirefoxPortable and PortableThunderbird users: They can split binary and profile directories under NTFS in different folders with read and write permissions respectivly. I recommend this policy, if the portable application is started on unknown systems with sometimes hazardous (i.e. virus infected) environment.
Microsoft advices not to format flash drives with NTFS. XP even refuse to format a flash drive with NTFS in standard mode. One has to revoke this obstacle manually by changing the selection in the hardware device management. The reason may be, that NTFS permanently accesses drives formatted with NTFS even if the drive isn't in use actually.
Mozilla don't recommend refusing write access to binary files, although there are obvious reasons not to propagate such an illposed policy. Nevertheless PortableThunderbird and FirefoxPortable work fine with my little invention.
Last not least chipdrive producer tell about a limited read/write access of certain memory cells on the device. Well, I use my Memorex Traveldrive for more than 2 years and NTFS with portable applications for more than 1 year. I haven't noticed any performance lags or malfunctions yet.
May be I'm lucky (ignoring all the well-meaning people and going my own way), but may be on the other hand the more I believe the more bogus bullshit I get told.
The only bad news: There may be a bug with FirefoxPortable profile folders with Windows 2000 systems. May be someone find suggestions.
When I analyzed the symptoms of the bug again I concluded that it has something to with the launcher and not with firefox 2. I startet Firefox 2.0 with the old PortableFirefox.exe launcher (not the buggy FirefoxPortable.exe).
All the described bugs vanished. Maybe there are other disadvantages I still haven't experienced, but in first instance all is working fine. And I think after the launcher did his task properly there is hardly something what can go wrong later. But I have to be careful: I first thought too FirefoxPortable.exe did its job properly.
You can blame the launcher if you'd like. But you're the only one encountering this issue, and it's because you're using an unsupported setup. You must have write access to the profile and firefox directories. If not, certain things will break. No doubt about it. That's the way it is. That's the word from Mozilla. That's the only setup that is supported.
The only reason I can think that the older launcher may not encounter the problem is because it is not Vista compatible and requires elevation of privs to admin level whereas the new one runs under the current privs. You're welcome to continue to use it, but know that your setup won't work on any Vista machines you encounter unless you're logged in as an admin. And the old PortableFirefox.exe is not supported anymore.
And the NTFS permissions won't help protect you from a virus. If you plug into a PC with a virus, that virus will easily be able to overwrite or alter any files you have marked as read-only in NTFS without any problem. (Remember, that virus is running with admin privs on that PC even if you're only logged in as a Guest, so it can do anything it wants to your removable drive.) The only way to protect files on a drive when plugging into a virus-infected PC is to have a whole drive with a write-protect switch.
Sometimes, the impossible can become possible, if you're awesome!
"And the NTFS permissions won't help protect you from a virus. If you plug into a PC with a virus, that virus will easily be able to overwrite or alter any files you have marked as read-only in NTFS without any problem."
No, it isn't so easy as you think. Admins have the possibility to get all permissions. But this doesn't mean that they have actually all permissions. If you try a NTFS secured stick on a virus infected machine, it depends of the sophistication of the virus programmer whether he makes the USB drive free for write access or not. It's up to you to try it yourself: Try to write on a flash drive on a machine where you have admin rights and the NTFS file is generated from another machine's admin with the same name. Good luck.
So I found only my free directories infected when I returned from a visit in an Internetcafe. The gadget works as long as nobody (of the virus programmers) take notice of it.
But the main issue, not covered by this thread, is: What can we do running portable applications in rough environments? Write-protecting a stick is not working because certain parts must have write access. And if we think of flash drives with a splitted memory (or 2 flashdrives with one of them readonly) then new problems arise:
How to tell the portable application about the path to the other drive (the drive letter is probably changing!)?
What about a policy to require write access to program files' directories (Mozillas last word - maybe they are right because the statement terminates their existence)?
How to protect read only folders from spying (cryptographic measures)?
New ideas appreciated.