torproject version: 5.0.3 (based on Mozilla Firefox 38.3.0)
portable apps is 41.0.2
Both, concurrently on MS XP.
As far as I know, both claim they won't interact with the other.
Can you verify, or otherwise comment, on the following:
Starting 41.0.2-portable after the torproject's firefox is running yield a message that there is another version of firefox running. 41.0.2-portable needs that other version closed before it can run. Reversing the start order, that is starting torproject's firefox after 41.0.2-portable is running, seem to work. Although I do suspect that there are still some bad interaction.
Since in the 1st order, that is 41.0.2-portable after torproject's firefox, 41.0.2-portable didn't start, I haven't disabled the addons I have for 41.0.2-portable before trying. It is apparent that torproject's firefox uses the, perhaps modified, noScript addon. I use it for 41.0.2-portable too.
You are here
Does 41.0.2-portable and torproject.org's firefox has problematic interaction?
October 17, 2015 - 10:19am
#1
Does 41.0.2-portable and torproject.org's firefox has problematic interaction?
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
Tor is just Firefox inside so it has the same issues as any other Firefox or Firefox-based browser not supporting running multiple instances or profiles. You should not do this in a portable scenario. You can force it to work with AllowMultipleInstances which passes the -no-remote switch to firefox.exe. I believe Tor does this as well by default. Note that we don't recommend using this in a portable situation as it may leave some non-personal files behind.
Sometimes, the impossible can become possible, if you're awesome!
http://kb.mozillazine.org/Opening_a_new_instance_of_your_Mozilla_applica... has an important comment about never using -no-remote to start the "default" profile. I only skimmed that URL.
41.0.2-portable crashed while torproject's firefox was running. Restarting 41.0.2-portable, and also deliberately closing it and then firing it up had no seemingly colision with the running torproject's firefox.
On the other hand, installing 41.0.2-portable from scratch did seem to collide with the running torproject's firefox.
What matters is the launcher version. So if Firefox portable was updated using the Firefox updater it would have the old launcher that doesn't correctly alert of already running instances. For browser is an unofficial modification of Firefox and makes use of a lot of configuration hacks to accomplish its goals. These hacks weren't really designed to be used like they are so it corps lead to some unexpected behavior, especially when using no remote to run multiple instances.
Sometimes, the impossible can become possible, if you're awesome!
I updated the portable-firefox by closing the running 41.0.1-portable, and hopefully when it was shutdown, running 41.0.2-portable.paf. I am waiting for the portableapps new version, and not using upstream to update.
Are you able to see my initial problem on a virtual machine?
There are no issues as this is expected behavior. You must use AllowMultipleInstances to get multiple instances working. Tor likely launches with -no-remote already. We don't support running Firefox Portable alongside the Tor modded Firefox as the configuration hacks could cause unexpected results. Realistically, we don't support or recommend multiple Firefox instances full stop as it's not supposed to be used that way.
Sometimes, the impossible can become possible, if you're awesome!