-no-remote is not viral and therefore is useless for custom themes




11 years ago
11 months ago


(Reporter: toad, Unassigned)


2.0 Branch

Firefox Tracking Flags

(Not tracked)




11 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20070309 Firefox/
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20070309 Firefox/

My application creates a firefox profile because it has some unusual requirements (e.g. it serves pages by HTTP but they are rather high latency, so we need a high network.http.max-connections; security also benefits). We use -CreateProfile successfully, and we launch firefox with firefox -no-remote -P <profile name>. So if there is already a normal firefox running, everything works fine: there is a normal firefox window, and a window with the custom profile. But if there isn't, and the user starts one before he exits the customized firefox, he will get another firefox window using the customised profile. This leads the user to assume that we have clobbered his default profile, and therefore to get rather mad!

Reproducible: Always

Steps to Reproduce:
1. Create a custom theme called freenet.
2. Start firefox with -no-profile -P freenet.
3. Start another firefox without any arguments.
Actual Results:  
The second firefox window also used the freenet theme.

Expected Results:  
The second invocation of firefox should realise that the first was started with -no-remote (it should remember), and not coalesce with the first.


7 years ago
Version: unspecified → 2.0 Branch


7 years ago
Summary: -no-profile is not viral and therefore is useless for custom themes → -no-remote is not viral and therefore is useless for custom themes

Comment 1

7 years ago
I'm not sure the above is the whole story. We got a lot of users complaining about firefox always starting the new profile even if they uninstalled freenet and reinstalled firefox. (We did remove the profile on uninstalling, but that's not the point). Somehow the default would get set to the new profile rather than the old default, thus making firefox permanently unusable.

Comment 2

7 years ago
We are not using this at present but the fact that -no-remote -private <url> doesn't work means we are considering using a profile instead... but only if this is fixed. :|
Not a shell integration bug. Most likely toolkit -> startup and profile system
Component: Shell Integration → Startup and Profile System
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.