A bug report opened about nine months ago on Mozilla’s Bugzilla bug tracking site for Firefox suggests that the organization could disable reading the user.js file of the Firefox browser by default in the future.
If you have not heard about user.js before, it is a configuration file that controls preferences in the Firefox web browser. One of the main advantages over Firefox’s preferences file is that it has priority and that it is a user-owned file that is left untouched when Mozilla makes changes to the browser.
I suggest you check out the ghacks user.js repository on Github for detailed information and an extensive file to improve privacy and security of the Firefox web browser.
The bug reporter states in the description that he “never fully understood the point of having this file”, that people have abused it and “broke stuff” in Firefox, and that it offers nothing that cannot be achieved by modifying the default preferences file, or by using Enterprise policies. Additionally, since Firefox needs to check for the file’s existence regardless of whether it exists or not, it is causing “additional IO early on startup”.
According to telemetry that Mozilla gathered, about 3% of Firefox installations that report telemetry use user.js files.
Others have pointed out early in the discussion that there are advantages, including maintaining Firefox preferences over multiple systems, when reinstalling Firefox, moving it, or installing a new version or edition of the browser. Another benefit that was pointed out early in the discussion is that user.js preferences are permanent (unless edited by the user) whereas prefs.js preferences are not as they may be modified by Mozilla at any time.
As Mike Kaply puts it, “he advantage here is that you can have a file that you keep around and just drop into a profile directory and Firefox doesn’t mess with it”.
The suggestion brought forward is to disable user.js by default but introduce a preference in Firefox that users need to enable actively so that the user.js file is read again.
While that would ensure that Firefox retains support for user.js configuration files, it would block Firefox from reading the file after the change lands even if it is in use; this would mean that a user’s desired configuration, e.g. related to privacy or security, won’t be honored by the browser until the configuration change that enables the reading of the file is made.
The bug reporter already revealed long term plans to remove support for the file entirely from Firefox.
Longterm, I’d really like to evaluate whether we can remove support for this file entirely, because it just fundamentally doesn’t really make sense to have so many different files that all control the same thing, but it probably requires figuring out why so many people use it, which we don’t have cycles to do. Nor is it really obvious how we’d go about doing so: if we think a substantial portion of people aren’t aware they’ve done this, just doing a survey “why do you have this file” is unlikely to be enlightening; we could try doing telemetry on what prefs get set, but we’d probably have to have some kind of strict list of prefs we allow ourselves to send back to avoid passing back user data, which again might not get us the data we need.
Here is what I think about all this
The user.js file is an integral part of Firefox. It is used by about 3% of all Firefox installations and it is likely that the number is a bit higher even considering that many user.js files such as the Ghacks user.js have Telemetry disabled by default.
Making this a pref in about:config would probably not lead to a mass exodus of users and it would probably also keep the outcry contained. It seems possible that lots of users would migrate to another browser, e.g. Waterfox or Palemoon/Basilisk, that continues to support the functionality, or migrate to a Chromium-based browser
While I understand Mozilla’s drive to improve Firefox startup performance, it needs to be weighted against the breakage that the change causes.
Lots of features have been removed or been broken in the past already in Firefox by engineers who sometimes could not come up with a reason for using them or at other times ignored the marginal number of users that used a feature. Maybe, it is time to