1595865 - update about:config to show extension control of a preference

Status: NEW

(Toolkit :: Preferences, enhancement, P2)

Description

[Shane Caraveo (:mixedpuppy)]

This is going to need some further definition about how it should work, but we would like to have some indicator in about:config if an extension controls a preference.

Ideally some icon would indicate that, and the pref would not be changable without the user accepting some dialog that tells them changing the pref will likely interfere with the operation of an extension.

Comment 1

[:Paolo Amadini]

See bug 1595860 comment 1 for the performance and architecture considerations.

Comment 2

[:Paolo Amadini]

(In reply to Shane Caraveo (:mixedpuppy) from comment #0)

the pref would not be changable without the user accepting some dialog

As a general note, we tried to avoid modal dialogs as much as possible, although a "confirm" box may not be excluded for special situations like this one. Modal custom dialogs, on the other hand, are generally too much work in HTML.

The interface you go for may depend on how much engineering effort you want to put into this feature. In turn this may depend on what exact problem this is essentially trying to solve. I guess it's about someone modifying a preference (by own initiative, by following a tutorial, or by recommendation) that will later be reset to a different value anyways. Maybe an icon and some parenthetical text following the value could be enough for this, without affecting whether the preference can be actually edited.

Comment 3

[Shane Caraveo (:mixedpuppy)]

As a general note, we tried to avoid modal dialogs as much as possible

Whether it is modal or not, a dialog or something else, doesn't really matter to me. There just needs to be a confirmation that the user understands the potential for making an extension operate incorrectly.

A bonus step (and now I think of it, we should just do it as well) would be to change the setting to user-set, so the extension would be properly notified that it no longer controls the setting.

I guess it's about someone modifying a preference (by own initiative, by following a tutorial, or by recommendation) that will later be reset to a different value anyways.

No, it's about changing a pref that an extension currently controls. If a user tries to change that in about:preferences, the ability to change it is locked out. The user can regain control by disabling the extension (soon, for some settings, it will be selectable). If a user changes something in about:config, there is no indication that an extension has set the pref. Changing it could have side effects for the extension, the user should be aware of that when making the change.

Comment 4

[Shane Caraveo (:mixedpuppy)]

Attachment: Screen Shot 2019-11-13 at 12.08.16 PM.png

In this screenshot, there are icons on the right for modifying the prefs in various ways.

I would suggest that the first icon shows the generic extension icon if it is controlled by an extension. Clicking the icon results in a dropdown menu that has something like:

X My Tabs (Extension) <-- "X" is a checkmark or whatever
Another Addon (Extension) <-- this would change the values to the settings used by this extension
Customize <-- this allows the user to set the pref
Reset <-- this just resets to default or prior user-set values

With something like this, if the user switches to something, we can properly update our preference management and notify the extension of the change.

As well, multiple prefs may end up being changed at once. The proxy.settings api for example, sets a dozen or so prefs when it is changed. Resetting/changing any one of them in about:config would result in all of them being changed either back to defaults or to prior user-set values.

Comment 5

[:Paolo Amadini]

The getManagedPrefDetails API that landed in bug 1595860 is asynchronous, which means that some thought should be given about how it can be properly integrated with the synchronous "about:config" code.

The fact that the API is asynchronous can in fact be an advantage, because we should be very careful to prevent the page from blocking on calls to other modules. An exception or deadlock may make it more difficult to fix issues in those modules that may be caused by incorrectly set preferences.

In other words, making a change in "about:config" should not be able to break "about:config". Ideally, we should have regression tests that simulate errors or deadlocks in the API provided by the WebExtensions module.

I'll not be able to review code for this feature as I have other commitments now, but I'm thinking Jared might provide some guidance on how to move forward with this code, and either review or identify a reviewer. He is already the triage owner of the Bugzilla component associated to the code, and owner of Preferences in the front-end, of which "about:config" is now part.