This has come up a number of times recently for open bugs, and there is also an issue currently with chrome_settings_overrides when setting the home page which should be addressed. The basic issue is that the ExtensionPreferencesManager which is used when an extension wants to change a setting is not designed to deal with cases where a user changes the setting themselves, outside of a WebExtensions API. This can result in unexpected behaviour when an extension is disabled or uninstalled, as that can cause a setting to be "rolled back" to a value that the ExtensionPreferencesManager believes it should have, but that value may not be accurate if a user has manually changed a setting in the interim. We chose to ignore the case when users manually change settings via about:config, and that decision may or may not still be valid, but now that we have the ability for extensions to control settings which can be changed more easily (because they are exposed via the UI) we need a concrete solution to that issue. It is also likely that more of these will be added in the future. On possible solution is to use default preferences. It has been suggested in the past that rather than writing user prefs via the ExtensionPreferencesManager, we could write default prefs. I think this would cause more problems than it solves, which I’ll discuss below. - With this implementation extensions could never override a user-set pref. If that is something we want, then that is a good thing, but I suspect that is something we do not want. - Question: Should user-set prefs be overridable by extensions? - When a user manually sets a pref to a default value, the Preferences system no longer treats it as a user pref, even though the user set it manually. This means that even with default prefs we’ll still have the issue of the ExtensionPreferencesManager getting out of sync with user-set prefs if the user set the pref to its default value. Another solution would be to clear the precedence queue when a user changes a pref. This solution, which was discussed in bug 1361364, involves watching for manual changes to prefs and then clearing out the precedence queue when one is detected. We are essentially setting things back to square one when a user makes a manual change, and any extension that wishes to change the setting will have to do so again. This solves the roll back issue, and also ensures that when an extension does request a change to a setting that it will record the correct initial value. An obvious issue with this approach is that we'll likely need to maintain separate code for each of the settings that need to be watched, as we cannot simply watch for pref changes as those would also be caught any time an extension makes changes to the pref. I am keen to hear feedback and suggestions on these approaches, and/or suggestions for other approaches.

Andrew (and anyone else interested), I'd appreciate your feedback on this.

I think its hard to evaluate what to do here without a more concrete picture of how extensions might use these sorts of APIs. As a general rule, I would expect the browser to give a higher priority to my direct actions (ie, I express my desire to change a setting by making a selection in about:preferences) than to an indirect action (ie, I express my desire to change a setting by installing an extennsion that changes that setting). Unfortunately, that is ambiguous since we can't really tell whether the action of setting a preference to its default value in about:preferences means that the user really wants that specific value, or that they just want the default behavior, and would be okay to have that overridden by extensions. Getting back to the original point, I think this bug is overly general and not something we can realistically make progress on. I think discussing individual preferences and then seeing if some general pattern emerges is more likely to lead us somewhere productive. Whether it happens in this bug or in others, what are some specific extensions that want to modify settings that are exposed in about:preferences?

(In reply to Andrew Swan [:aswan] from comment #2) > I think its hard to evaluate what to do here without a more concrete picture > of how extensions might use these sorts of APIs. As a general rule, I would > expect the browser to give a higher priority to my direct actions (ie, I > express my desire to change a setting by making a selection in > about:preferences) than to an indirect action (ie, I express my desire to > change a setting by installing an extennsion that changes that setting). > Unfortunately, that is ambiguous since we can't really tell whether the > action of setting a preference to its default value in about:preferences > means that the user really wants that specific value, or that they just want > the default behavior, and would be okay to have that overridden by > extensions. Yes, this is part of the problem. If we decide that we want to enforce that (i.e., an extension cannot change a setting that a user has set themselves) we need to address that. I'm not sure how we can do that other than changing the code in Firefox that responds to the user action of changing the setting, to do something to indicate a user has chosen a value, regardless of whether it's the default or not. Simply using the prefs system as it stands right now won't work because of this default issue. I'm still not sure that's what we want to do, though. If we do that it will be impossible for an extension to override a user setting, so it seems like we'd also need to figure out a way to deal with that. Maybe we would need some new UI to ask a user if they want to allow an extension to override a user-set setting? > > Getting back to the original point, I think this bug is overly general and > not something we can realistically make progress on. I think discussing > individual preferences and then seeing if some general pattern emerges is > more likely to lead us somewhere productive. Whether it happens in this bug > or in others, what are some specific extensions that want to modify settings > that are exposed in about:preferences? Fair enough. I do think this is a problem we need to solve somewhat in general, but I agree that we can come up with the best solution by looking at individual use cases. Bug 1368545 is a current bug (i.e., not proposed/requested new functionality) which really should be addressed as soon as possible, so perhaps it's best to discuss what we want to do about that case in the bug itself. I will move the discussion there, for now.

Due to the landing of bug 1368545 I am going to mark this as fixed. We will want to consider each setting that we expose via an API and which is also exposed via the UI separately, and this is currently being done as part of "Project Jazz". Bug 1368545 introduces a safeguard for those APIs we do want to implement prior to addressing the UI issues.