Search Support

Avoid support scams. We will never ask you to call or text a phone number or share personal information. Please report suspicious activity using the “Report Abuse” option.

Learn More

Cuireadh an snáithe seo sa chartlann. Cuir ceist nua má tá cabhair uait.

"about:config" setting keeps resetting after every FF update

  • 4 fhreagra
  • 1 leis an bhfadhb seo
  • 11 views
  • Freagra is déanaí ó Klimat

more options

So in FF68.0 Mozilla devs have for some reason screwed such a basic thing as drag and drop from the browser into Windows file explorer. The best fix I was able to find to restore drag and drop proper functionality is to go into "about:config" page, find "browser.launcherProcess.enabled" setting and switch it to "false". The problem is, the setting in question just keeps resetting to "true" on its own after each and every browser update, so I had to manually change it back to "false" after FF69 update, FF70 update, FF71 update and FF72 update, basically 4 additional times already if not even more (I don't quite remember about XX.0.1 types of updates). It's frankly getting ridiculous and extremely annoying by that point. Is there a way to stop FF from screwing my "about:config" settings without my consent?

So in FF68.0 Mozilla devs have for some reason screwed such a basic thing as drag and drop from the browser into Windows file explorer. The best fix I was able to find to restore drag and drop proper functionality is to go into "about:config" page, find "browser.launcherProcess.enabled" setting and switch it to "false". The problem is, the setting in question just keeps resetting to "true" on its own after each and every browser update, so I had to manually change it back to "false" after FF69 update, FF70 update, FF71 update and FF72 update, basically 4 additional times already if not even more (I don't quite remember about XX.0.1 types of updates). It's frankly getting ridiculous and extremely annoying by that point. Is there a way to stop FF from screwing my "about:config" settings without my consent?

All Replies (4)

more options

While I can't explain why this occurs, the following steps should force this setting (and any other) persist for you user profile when updates to the browser are made:

1. go to "about:support" 2. Under the "Application Basics" section, find the "Profile Folder" row and click on "Open in Folder". 3. Create a text file in this folder containing the below lines of text:

   /* Make sure this comment is the first line of text in the file. Firefox will always ignore the first line of the file */
   user_pref("browser.launcherProcess.enabled", false);

4. save the file as "user.js" 5. restart Firefox


The settings defined in this file should always override anything the browser tries to set. It also means you can't change the settings defined in this file from about:config anymore since your user.js file always overwrite them the next time the browser starts up.

Essentially, any changes you make to settings via about:config or the standard about:preferences UI, get saved to a file called "prefs.js" with the same syntax as stated above:

   user_pref("<setting_name>", <value>);

Each time Firefox starts up, it loads in all the system default settings, then overrides those with whatever is in prefs.js and then overrides everything in both of those with whatever's been manually defined in user.js.

Since prefs.js is controlled by the browser, it's liable to be modified during updates without your consent. user.js, however, is considered a user-controlled file and, to my knowledge, shouldn't be altered during updates.

I've been on Nightly for 6 months or so now, receiving updates everyday, and have not had anything in my user.js file overwritten once.

Athraithe ag d.mattera ar

more options

Thanks! I did just what you said, I'll report back if it worked or not the next time FF updates!

more options

Hello, You can fix your custom settings in a config file using autoconfig. It works for both RR and ESR.

Athraithe ag cor-el ar

more options

Ok, FF72.0.2 update just happened and I can confirm "user.js" method unfortunately does not work. Any other suggestions?