1751503 - Firefox should reflect browser.launcherProcess.enabled preference if set in user.js

Status: NEW

(Firefox :: Launcher Process, defect)

Description

[registrazioni.gorman]

+++ This bug was initially created as a clone of Bug #1684223 +++

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:84.0) Gecko/20100101 Firefox/84.0

Steps to reproduce:

I edited Firefox config ("about:config"), more than one time, then searched for "browser.launcherProcess.enabled" and set it to FALSE, because I prefer less security but the ability to drag-n-drop images on desktop. Then I updated Firefox.

Actual results:

Preference "browser.launcherProcess.enabled" is reset to TRUE every time I update Firefox to a new version.

Expected results:

My explicit preference should be maintained.

---

I don't understand why this shouldn't be fixed or, at least, an option provided to avoid having to change this every single time FF gets updated.

Stuff like "it's by design, suck it up" is what I would expect from Chrome, not Firefox. I know what I'm doing, I have been doing it for the past ten years, literally. I want Firefox to run under my VPN, while the rest of the system works outside of it. To do that I need to use FprceBindIP. To use that I need browser.launcherProcess.enabled set to False.

I always do it when I update. It's not as if you devs are somehow convincing me that I shouldn't be doing it. If I explicitly decide I want that setting to be one way, why should you force feed me a setting I have to change at every single update?

This is even more grating as it's mandatory to be able to browse under VPN while leaving the system outside the VPN. At least, that's the only way I've found so far (and I've been looking). So you're forcing me to compromise my privacy for... what, exactly? Having "safe" defaults I agree on. Forcing "safe" defaults even when a user explicitly wants to change them it's borderline offensive.

If there's a reason why the setting is reset at each and every update, please explain it.
Saying "it's by design", the way I read it, translates to "by design we choose to override clearly expressed preferences by our users because we know better, even though they have to agree on assuming responsibility when entering about:config".

Comment 1

[Pablo]

see comment below.

Comment 2

[Pablo]

Hi there

I am unable to replicate this, I am on windows 10 64 bit by the way, are you on the same OS ? what firefox version was the one you updated from?

• i downloaded firefox 95 release and launched it offline.
• then i went to about:Config and i changed browser.launcherProcess.enabled to false
• then i went online and updated firefox
• When Firefox restarted, it was updated to 76.0.2 and the browser.launcherProcess.enabled is still False.

Are you sure you are using the same profile before updating?

Does this issue occur with a fresh profile? you can find the steps here:
https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles?redirectlocale=en-US&redirectslug=Managing-profiles#w_starting-the-profile-manager

Does this issue occur in the latest nightly version of firefox? Here is a link from where you can download it:
https://www.mozilla.org/en-US/firefox/channel/desktop/

What you can for now, is to create a user.js file and insert it on the specific profile folder that you are using. That will always force that setting to false every time you launch firefox: http://kb.mozillazine.org/User.js_file
you need to include this line in the user.js : user_pref("browser.launcherProcess.enabled", false);

Please let us know
thanks.

Comment 3

[registrazioni.gorman]

Thank you for your reply and suggestions, Pablo.

I'm really surprised you found a different behavior when installing from scratch. I have a single profile and I've never used a different one.

I will try what you suggested for user.js.

Aaand... strange things keep happening.

I have added

user_pref("browser.launcherProcess.enabled", false);

to the user.js file in the profile folder (there's just that single profile folder under C:\Users\gorman\AppData\Roaming\Mozilla\Firefox\Profiles)

I have checked the content of prefs.js in the same folder and it contained this line:

user_pref("browser.launcherProcess.enabled", true);

Now, from reading the description here: http://kb.mozillazine.org/User.js_file I expected the user.js file to prevail over prefs.js but that doesn't appear to be the case.

1. I add user_pref("browser.launcherProcess.enabled", false); to user.js
2. I delete user_pref("browser.launcherProcess.enabled", true); from prefs.js
3. I close Firefox and then relaunch it.
4. browser.launcherProcess.enabled is set to true both in the about:config interface AND prefs.js.

I don't know what is adding that line in prefs.js after I have deleted, since user.js is telling Firefox to do the opposite.

Comment 4

[registrazioni.gorman]

It looks like user.js is not being used to do what is supposed to do. If I delete the browser.launcherProcess.enabled preference, it's reinstated as defaulting to true, notwithstanding user.js telling FF to add it as false.

Comment 5

[Pablo]

I tried one more time today :

• i installed release version 95 from scratch
• then created a new profile, and launched Firefox
• browser.launcherProcess.enabled already shows up as False.
• updated 95 to 96.0.2 and i see it is still False.

In my case its not changing, but if i install Firefox 96.0.2 from scratch and i launch it with a new profile, that setting is set as TRUE by default.

Component for the bug is already set for launch process. perhaps the Devs might know why it is changing on your machine

regards

Comment 6

[registrazioni.gorman]

Thanks Pablo for looking into this and trying to help. The thing I don't understand is why the user.js is completely ignored.

Comment 7

[(No longer employed by Mozilla) Aaron Klotz]

As the original author of the code in question, I'm reclassifying this as an enhancement request: As I have previously described in the bug this one was cloned from, the pref behaviour is by design. By saying it is "by design," I mean that, the functionality controlled by this pref does not work the way the reporter is believing it to work. A bug would imply that this pref is not working as intended. In fact, this functionality is working precisely as intended, however the reporter is requesting a new behaviour that should be considered distinct from the existing design.

• The browser.launcherProcess.enabled pref was never designed to be a user-controlled toggle. It was added as an emergency kill switch during the rollout of the launcher process, so that if the launcher process and the browser were not starting correctly in sequence, we could temporarily shut it off. This would ensure that we would not brick people's browsers if there was a compatibility issue that arose during rollout.
• The pref resets upon upgrade under the expectation that fixes have been made to Firefox that might solve whatever issue was occurring previously, therefore we should try again with the new release.
• It doesn't work with user.js because it was never intended to be a user-controlled pref.

Remember, about:config prefs are not considered to be supported. There is no guarantee that prefs work in any specific way.

The entire impetus for wanting this change strikes me as an instance of the XY problem. The reporter wants to run ForceBindIP on Firefox. They believe that the launcher process interferes with that, hence they want to turn it off. But why exactly is the launcher process causing problems with ForceBindIP? Perhaps a more appropriate solution is in order.

Personally I don't think that allowing security features to be disabled in ways that add risk for the majority of users is the way to go.

Comment 8

[registrazioni.gorman]

(In reply to (No longer employed by Mozilla) Aaron Klotz from comment #7)

• The browser.launcherProcess.enabled pref was never designed to be a user-controlled toggle. It was added as an emergency kill switch during the rollout of the launcher process, so that if the launcher process and the browser were not starting correctly in sequence, we could temporarily shut it off. This would ensure that we would not brick people's browsers if there was a compatibility issue that arose during rollout.
• The pref resets upon upgrade under the expectation that fixes have been made to Firefox that might solve whatever issue was occurring previously, therefore we should try again with the new release.
• It doesn't work with user.js because it was never intended to be a user-controlled pref.

Remember, about:config prefs are not considered to be supported. There is no guarantee that prefs work in any specific way.

The entire impetus for wanting this change strikes me as an instance of the XY problem. The reporter wants to run ForceBindIP on Firefox. They believe that the launcher process interferes with that, hence they want to turn it off. But why exactly is the launcher process causing problems with ForceBindIP? Perhaps a more appropriate solution is in order.

Personally I don't think that allowing security features to be disabled in ways that add risk for the majority of users is the way to go.

Thanks for taking the time to explain.

Don't know about the XY problem in this case. ForceBindIP's author has this to say on the subject:

Firefox requires the about:config?filter=browser.launcherProcess.enabled preference set to false, otherwise ForceBindIP attaches to the launcher and not the actual program.

So I don't think there could be a different way to go about this. Chrome doesn't even support the use of ForceBindIP anymore, in any way.
Now, there might be good security reasons for this, I honestly don't know. But if this was doable under user.js (and thanks for clarifying it doesn't work, although the wiki should be updated, because nowhere it states that stuff found under about:config cannot be overridden through its use), then I think it would be far beyond what "the majority of users" would do.

More generally speaking, if not even Firefox remains as the browser that can be configured to cover its users need, deciding all users have the same needs and adhering strictly to those... well, as a almost 20 years user it would be a sad day for me. For the greater good? I don't know, it's not as if we're lacking in the "browsers that think they know what their users want" category. But maybe it's just me, I can accept that. First world problems and all that.

Comment 9

[registrazioni.gorman]

Also, don't care one way or the other, but given https://support.mozilla.org/en-US/kb/profiles-where-firefox-stores-user-data I still think this is a bug. As it introduces behavior that is not in line with official documentation for Firefox. I am no dev, so maybe it technically isn't, I don't know.

The optional user.js file, if one exists, will override any modified preferences.

Otherwise the above should be changed, I guess. As there are preferences in about:config that cannot be overridden by user.js (don't know if browser.launcherProcess.enabled is the only one).

Having said all this, the only thing I strongly hope is that to solve the problem the preference isn't simply put out of user's reach. Thanks in advance for not doing that, please.

Comment 10

[Adrian Florinescu [:aflorinescu]]

I kinda'of agree with everyone's oppinion. The process launcher is applicable to Windows only (at least as far as I can remember) and the idea behind it is to be an intermediar step to launching Firefox to avoid malicious hooking into the Firefox process. As Aaron explained there might be circumstances in which interaction with other software might be detrimental to the health of Firefox being launched by using the launcher, hence the disable/enable mecanism behind it.

IMO the issue here is the fact that the user.js should be persistent and in this case it is not. My oppinion, at least in the case of using an user.js is that the user preference should be respected.
Not sure if in the case of about:config modification we'd know when it was user disabled or it was Firefox level disabled due to a potential issue.

Moving back to defect type and marking the latest relevant versions.

Steps to reproduce:

1. Create an user.js with user_pref("browser.launcherProcess.enabled", false);
2. Start Firefox.
3. Check about:config for the value of browser.launcherProcess.enabled .

Reproducible with: 102.3.0esr, 105.0.3, 106.0 RC, 107.0a1 (2022-10-12) on Windows 10.

Comment 11

[lucio]

+1 here dealing with this same behavior that user.js setting is not being respected.

I also need to use ForceBindIP, and I don't care if a flag is being reset, as long as user.js is respected.

I can confirm it still happening on 108 and 109.

Comment 12

[Li Shanchao]

user.js doesn't work during my Firefox upgrading from 113.0.1 to 113.0.2.