For modifying Firefox use user.js instead of modifying prefs.js

[silverhook]

Problem description

When it comes to modifying Firefox settings, the script currently searches for different prefs.js and modifies it there.

This is heavily discouraged:

Preferences Saving

Usually when the user specifically commits a preference change via user interface such as the Preferences dialog, the application saves the change by overwriting prefs.js. On application exit, all user-set preferences are saved to prefs.js. This also means that preferences initially set by user.js will also be saved to prefs.js.

Do NOT edit prefs.js directly.

Note the application never changes user.js, so on launch user.js overrides conflicting preferences from the previous application session.

When prefs.js is written, it only saves user preferences which are different from the default. The exception to this is a preference read using sticky_pref() - these preference will be written whenever the preference has a user value even when it is the same as the default.

https://udn.realityripple.com/docs/Mozilla/Preferences/A_brief_guide_to_Mozilla_preferences#Preferences_Saving

Proposed solution

Write the changes in user.js instead.

Will likely make the script a bit shorter and easier too :)

[undergroundwires]

Hi @silverhook , thank you for your feedback with nice explanation and sources. Let me know in future if you see any other improvement area, I'm looking forward for this kind of feedback.

You're right. It sounds safer to do changes on user.js to not take any chances to corrupt prefs.js.

Thinking about the implementation, I guess because user.js optional we should do some additional file management in scripts:

• Create user.js file in profile folder if not exists.
• On revert, if revert operation resulted in empty user.js file, delete the file.

[silverhook]

Hi @silverhook , thank you for your feedback with nice explanation and

sources. Let me know in future if you see any other improvement area, I'm looking forward for this kind of feedback. Happy to help. I’m not really a user, but a colleague suggested to check it out, so when I saw this I created the issue. More of a drive-by contribution :)

Thinking about the implementation, I guess because `user.js` optional we should do some additional file management in scripts: - Create `user.js` file in profile folder if not exists. - On revert, if revert operation resulted in empty `user.js` file, delete the file.

That sounds sane to me, yes.

[undergroundwires]

Fixed by 0.12.3

[ltguillaume]

If I understand the code for this correctly, I think this causes an unintended and confusing situation:

1. User sets something via privacy.sexy
2. user.js gets created/modified with the respective settings
3. User opens Firefox
4. Firefox copies over the settings from user.js into prefs.js
5. User tries to revert said settings via privacy.sexy
6. The line gets removed from prefs.js user.js by privacy.sexy
7. User starts Firefox thinking the setting is reverted, but because the setting is still present in prefs.js, it is in fact still in effect

[undergroundwires]

Hi @ltguillaume,

Privacy.sexy does no longer touches prefs.js since 0.12.3. See the code here.

So your flow is right but the step 6. The line does not get removed by privacy.sexy, it just removes the line from user.js.

Or did you mean that removing lines user.js does not cause Firefox to update prefs.js? Should privacy.sexy remove the line from prefs.js as well as user.js?

[ltguillaume]

Sorry, in step 6 I meant that it got removed from user.js.

Or did you mean that removing lines user.js does not cause Firefox to update prefs.js? Should privacy.sexy remove the line from prefs.js as well as user.js?

Yes, that's exactly what I meant.

[undergroundwires]

I can reproduce this.

It works if privacy.sexy sets the opposite value of the desired configuration. But it does not work if privacy.sexy deletes the configuration from users.json. And in most cases it should delete the configuration, not to toggle values because the goal is to match the default state and a) opposite values are not necessarily the default values b) default values change over time c) sometimes values are more than booleans.

I will push out Firefox configuration to all operating systems (Windows+macOS) too, so its important to get this stable. The only solution looks to be to modify prefs.json only if privacy.sexy is deleting a value on revert.

I created #282 for this issue only, I appreciate your opinion @atomGit, @TheAndr0id, and @silverhook on that issue if you're around.