I just have two suggestions for the PortableApps Launcher for Firefox, both of which concern the AllowMultipleInstances parameter in FirefoxPortable.ini.
The first concerns the fact that, when this parameter is set to False, the PAL searches for any instance of Firefox.exe currently running then refuses to start if there is one. From what I can see though, Firefox and it's PAL doesn't create or use any registry settings that would cause a conflict if two copies of Firefox are running and the only files that get read and written are those in it's Profile folder, which is confined to %appdata% for non-portable Firefox and the Data folder for portable. That said, I haven't extensively checked this so I could be wrong.
My setup currently is that I have two copies of portable Firefox on my PC that each has a separate profile which has different addon configurations, different cookies and suchlike. If I left the two Firefox portable configs the way they are, I can only run one at a time as I would get a "Firefox Portable is already running" error if I try start the second. My solution to this is to set AllowMultipleInstances to True for both copies.
This allows me to run both simultaneously but I also have an addon (Open With) which I use to send tabs and hyperlinks from one to the other. The new issue here is that when I try to do that, I get an error stating that "Firefox is already running, but not responding. The old process needs to be closed to open a new window". Looking through the PAL source code, I saw that the reason for this is because when you set AllowMultipleInstances to True, the PAL adds the --no-remote switch to Firefox's command line, which blocks that copy of Firefox from receiving links.
My solution to this was to modify the source code to remove the --no-remote addition from that part of the code and re-compile. Now, I can run both of my portable Firefox copies at the same time and pass data between them. I have been running it this way for the last two weeks or so and haven't noticed any issues so far.
My first suggestion is to either modify the AllowMultipleInstances parameter or add a new parameter to the INI file. This change would prevent you from running multiples copies of the Firefox that is in the PAL's App folder but allows you to run any Firefox that is outside that folder, including other copies of portable Firefox. This parameter also would not add anything to Firefox's command line (either --no-remote or --new-instance) as this would not be required.
The second suggestion concerns the fact that when you set AllowMultipleInstances to True in the INI, the PAL adds the --no-remote switch to Firefox's command line. Could you please look into passing the --new-instance switch instead for Firefox 67 onwards. Basically, this switch does most of what --no-remote does except that Firefox can still accept remote commands (e.g. URLs passed to it). This switch was previously not working for Firefox on Windows but it has now been fixed for v67: https://bugzilla.mozilla.org/show_bug.cgi?id=1535144
This second suggestion would apply to AllowMultipleInstances if it is left as-is and my first suggestion is applied by adding a separate parameter.
Visit the Community page
Join our forums
Subscribe to our email newsletter
Subscribe with RSS
Follow us on BlueSky
Follow us on Facebook
Follow us on LinkedIn
Follow us on Mastodon
Follow us on Twitter
Firefox, even when using -profile, will still use local directories and multiple instances may step on each other in several paths:
$APPDATA\Mozilla\Firefox\Pending Pings\
$APPDATA\Mozilla\Firefox\Profiles\
$APPDATA\Mozilla\Firefox\Profile\
$APPDATA\Mozilla\Firefox\
$APPDATA\Mozilla\SystemExtensionsDev\
$APPDATA\Mozilla\
$LOCALAPPDATA\Mozilla\Firefox\firefox\updates\0
$LOCALAPPDATA\Mozilla\Firefox\firefox\updates
$LOCALAPPDATA\Mozilla\Firefox\firefox
$LOCALAPPDATA\Mozilla\Firefox\
$LOCALAPPDATA\Mozilla\updates
$LOCALAPPDATALow\Mozilla
This set of files outside of Firefox's profile continues to expand with each release.
The launcher sticks around and cleans up after Firefox closes. It doesn't do that in the case of multiple instances, which is the main reason Firefox works as it does. That error you see, "Firefox is already running, but not responding. The old process needs to be closed to open a new window", is generated by Firefox itself because it's not really made to let multiple instances run simultaneously.
I can look into switching to --new-instance or similar, but the other stuff has to work the same, and you'll still be leaving things behind locally and risk the instances stepping on each other in the shared directories above. Personally, I recommend against using multiple instances and don't do so myself. I use containers which are built into Firefox now.
Sometimes, the impossible can become possible, if you're awesome!
Is it not possible to redirect those files to the Data folder by passing edited environment variables to Firefox? https://portableapps.com/manuals/PortableApps.comLauncher/ref/launcher.i...
"That error you see, "Firefox is already running, but not responding. The old process needs to be closed to open a new window", is generated by Firefox itself because it's not really made to let multiple instances run simultaneously."
Incorrect, Firefox generates that message when you try to do remote things (e.g. pass a URL to it) after banning it from doing so. If you don't place such a ban on it, that message doesn't appear.
I looked into containers and they don't do what I need. Every container uses the exact same addon install and configuration whereas my current approach does not have this problem. The other issue I have is that Firefox doesn't give any visual indication of what container a tab belongs to unless it's your active tab. The latter wouldn't be a problem if I could move the container tabs to a new window and have Firefox remember and open all windows on startup. I haven't had much success with that in the past, though.
I'm aware that it's due to -no-remote, but that's been the only way to handle multiple instances for years. I meant that we're not handling that error.
You can't redirect stuff with environment variables. Redirecting APPDATA breaks lots of stuff and would affect all apps launched from Firefox (say opening a PDF or DOC in another local app) as every process inherits the variables from the launching process.
Containers indicate which they are based on color in each tab with an underline. By default it's blue for personal, orange for work, etc. No, this won't separate out extensions, though.
Sometimes, the impossible can become possible, if you're awesome!
Fair enough, other apps inheriting those variables is a big problem. I am curious though, what exactly breaks by redirecting Appdata?
Also, the Containers thing was a fail on my part. I am using a UI mod that restores the Australis look to Firefox but I was using an old version that didn't display the container colours. Just updated to the latest and I now see that underline you mentioned.
It's more about launching other software as it can mess them up a lot. Also affects Flash plugin and some extensions. I don't know if Firefox reads LOCALAPPDATA or uses the API call. And there is no LOCALAPPDATALow environment variable.
Sometimes, the impossible can become possible, if you're awesome!
I have a test launcher to try this out: https://portableapps.com/node/63318
Sometimes, the impossible can become possible, if you're awesome!