This has probably been around for a while. According to the launcher source, these three INI params are required -
"${APPNAME}Directory"
"ProfileDirectory"
"SettingsDirectory"
So try using this INI -
[FirefoxPortable] FirefoxDirectory=App\firefox ProfileDirectory=Data\profile SettingsDirectory=Data\settings # PluginsDirectory=Data\plugins # FirefoxExecutable=firefox.exe # AdditionalParameters= # LocalHomepage= DisableSplashScreen=true # AllowMultipleInstances=false # DisableIntelligentStart=false # SkipChromeFix=false # SkipCompregFix=false # RunLocally=false
In this case, both the PluginsDirectory and FirefoxExecutable are set to blank by the launcher. This will make the launcher fail with an error. If you add the executable line, then the plugins directory will be empty and I'm sure something will go wrong.
The PluginsDirectory and FirefoxExecutable should probably be made required params as well.
it's not a bug. all entries are required. always been that way.
Sometimes, the impossible can become possible, if you're awesome!
I still think it should be optional which entries to use. Shouldn't really be hard--the Windows .ini APIs all accept default values.
All-entries-required wreaks havoc thanks to custom path support, as well. Even when all I want to do is disable the splash, I have to fill out every entry, including the paths--meaning DefaultData (and possibly other PortableApps features) get disabled because the launcher thinks I'm using custom paths.
I have to agree here. Maybe at one point in the past requiring ini entries made sense but as the spec is now it would be easy to use defaults for non-specified entries just as is done with no ini.
formerly rayven01
Huh, I was just going off the launcher source.
If what you're saying is true, then if any INI parameters are missing the INI sould be skipped and the default values used.
I described the problem and proposed a fix here.
Incidentally, the fix also allows for a global PortableApps.ini (for things like DisableSplashScreen).
-hea
I thought I remembered something like this problem mentioned before. But I couldn't remember exactly where, and I thought it only had to do with the "Live Firefox" mode of operation.
The original topic was about two minor copy-and-paste errors in the Mozilla scripts (one forced the default Data\settings regardless of INI config, the other only affected "people who have plugins in Data\Plugins and are running in live mode").
I followed up with the Code suggestion that addressed the problem you describe and updated my original post to reference it.
I guess the relevance of the latter got lost in the process. -hea