Tìm kiếm hỗ trợ

Tránh các lừa đảo về hỗ trợ. Chúng tôi sẽ không bao giờ yêu cầu bạn gọi hoặc nhắn tin đến số điện thoại hoặc chia sẻ thông tin cá nhân. Vui lòng báo cáo hoạt động đáng ngờ bằng cách sử dụng tùy chọn "Báo cáo lạm dụng".

Learn More

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

  • 4 trả lời
  • 1 gặp vấn đề này
  • 13 lượt xem
  • Trả lời mới nhất được viết bởi 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?

Tất cả các câu trả lời (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.

Được chỉnh sửa bởi d.mattera vào

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.

Được chỉnh sửa bởi cor-el vào

more options

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