Assigning to myself so it (hopefully) doesn't get lost.

It's not clear to me that making the setting editable by the user is the right solution here - I think we decided that extensions had control because otherwise you get into a weird state easily with each vying for control.  Typically if you don't like what an extension does, our advice is to uninstall it, rather than try to have a way to override it.

> Any extension that touches a setting now has to track the current value of the setting and provide a UI for the user to change it, essentially mimicking the whole chrome UI.

well, yes and no. If an extension *wants* it to be user-editable, then it should provide the UI for it, but that seems totally reasonable.  Additionally, "tracking" the current value is pretty easy, since we provide a .get() method on the content setting.

I ran into this problem while implementing my own extension: I wanted to write a simple JS toggler extension that enables/disables JS with a single click, but this behavior made it not very useful as all UI surfaces were disabled (page info buble, content settings and page action). So obviously, uninstalling the extension is opposite of what I want to do :)

> well, yes and no. If an extension *wants* it to be user-editable, then it should provide the UI for it, but that seems totally reasonable.  Additionally, "tracking" the current value is pretty easy, since we provide a .get() method on the content setting.

Just checked what happens when there are two different extensions modifying the same setting: Looks like the changes from the second extension are ignored. Callback doesn't indicate this, but there are also no settings changed events either. In this case, tracking the settings doesn't seem as straightforward to me when there are multiple extensions modifying the setting: They can't rely on .set() changing the extension, and they have to poll .get() to update the UI. Also, given how much logic we have in Chrome to display the patterns and settings, I'm not sure if we can expect an extension to provide similar UI. At the very least, whatever they implement would be simplified quite a bit, which again makes this API less useful than it can be (case in point, my dumb extension above :)

If we don't want to change the current implementation, would it be reasonable to add a flag to .set() to indicate that the setting should still be available to the user? That way at least current extensions relying on this behavior wouldn't break.

>  I ran into this problem while implementing my own extension: I wanted to write a simple JS toggler extension that enables/disables JS with a single click, but this behavior made it not very useful as all UI surfaces were disabled (page info buble, content settings and page action). So obviously, uninstalling the extension is opposite of what I want to do :)

Couldn't you just use a browser action that, on click, reads the value and sets it to be the opposite?

> Looks like the changes from the second extension are ignored. Callback doesn't indicate this, but there are also no settings changed events either. In this case, tracking the settings doesn't seem as straightforward to me when there are multiple extensions modifying the setting: They can't rely on .set() changing the extension, and they have to poll .get() to update the UI.

Hmm... I think we probably should indicate failure in the API if the set() doesn't stick.  Additionally, I'd be fine with adding a "onContentSettingChanged" event to the API, which would obviate the need for get-polling.

> If we don't want to change the current implementation, would it be reasonable to add a flag to .set() to indicate that the setting should still be available to the user? That way at least current extensions relying on this behavior wouldn't break.

I'm not totally against this, but might prefer to see if the other solutions would work first (since they would be desirable in either case).

This can be simply achieved by reordering the providers.

Currently, the extensions provider has higher priority than the pref provider. So extension-sourced settings always trump the user-sourced. If we reversed the order, extension settings would be treated as a recommendation.

We had a similar feature request in issue 106682, but for the policy settings. There, the suggested approach was to make the provider ordering non-static; the administrator could select whether policy is a recommendation or mandatory, and the policy provider would be put on the respective position in the order.

Another solution would be to have two providers, one above and one below user preferences, and a flag in .set() would then decide whether to put the new setting in one or the other.

Btw, the purpose of contentSettings API that I'm aware of is "what if someone wants to make a better content settings UI that we have natively in Chrome?". That means that user installs an extension, fully delegates the control to it, and then uses that extension's UI. From that perspective, the current behavior makes perfect sense.

But if we want to support both behaviors, it's not too difficult - happy to help with that.

I largely agree with @6 - the contentSettings API is meant to provide an alternate, better experience - not necessarily a complementary one (otherwise a user that installed a content settings extension would still have all their old rules, etc).  I'd be most interested in making the API better to enable use cases. :)  meacer@, would any of the suggestions in @5 be sufficient?

Just to reiterate my use case: I'd like to write a minimal extension that can toggle JS with a single button, while still allowing the user to edit content settings. I think msramek's suggestions in comment #5 (either a recommendation mode or a separate flag in .set()) will work perfectly for my purpose.

Now here are some random thoughts for your entertainment :)

>  the contentSettings API is meant to provide an alternate, better experience - not necessarily a complementary one 

I understand that the original intent of the API is to let extension authors implement their own UI, but I think that's a very ambitious goal, and a perhaps bit unrealistic. Our content settings model has been changing (per-origin permissions, incognito permission inheritance, etc.), and I don't think expecting extensions to keep up with that is fair. An extension providing a better experience will only be possible if the extension can replicate what Chrome has and add on top of it. This is a massive amount of work, not to mention it's not possible for an extension to replicate or change some parts of the existing UI (esettings in page info bubble, or the blocked action bubble).

As a very specific example: let's say an extension provides a UI that toggles a specific on a site and its subdomains. This used to be how content settings worked: Toggling JS on http://example.com added a filter for http://[*.]example.com. But now it's changed to a per origin model where toggling a setting on an origin doesn't add any generic filters. The change in the underlying model would break this extension. In general, extension implemented UIs will eventually drift away from Chrome's model.

> (otherwise a user that installed a content settings extension would still have all their old rules, etc)

Keeping old rules intact sounds like a desirable thing to me though, no? If the API can mimic user input, the current content settings would keep working the same way it is working now. It seems like that could obviate the need for an additional preference provider too, but I don't know the implementation well enough so don't take my word for it :)

Re #8: Yes, if extensions could simply simulate user input, then we would not need an additional provider.

However, a separate provider ensures that a) changes to settings are undone when the extension is uninstalled, and b) we can show a puzzle icon in the settings menu to indicate that it's controlled by an extension. And that's not just for content settings, but preferences in general.

Making extension-sourced changes to settings indistinguishable from user-sourced ones seems to me like an invitation for malware...

That's a good point. I agree we shouldn't remove the separate provider for exactly those reasons. I'm guessing a lot of extensions already rely on the current behavior as well.

Renaming the bug to reflect the latest proposals.

> Keeping old rules intact sounds like a desirable thing to me though, no?

It depends on the extension.  In the case of the extension you're writing, I agree - keeping user prefs is great.  In the case of the user installing an extension to replace chrome's settings, I think it could lead to a lot of confusion around why something doesn't seem to be working the way it should.

In regards to giving the extension a choice of whether or not to let the user override the choice, conceptually, that sounds fine.  Implementation-wise, though, I'm not sure how easy it is.  Reordering the priority of providers is simple, but is unconditional (thus breaking some use cases).  I don't know how we could do this on a per-API call basis - maybe have two extension providers, one higher priority than user settings and one lower?  But that seems a little complex... Is there a simple way of achieving this?

While I understand the desire, and you make good points about our own model changing, I'm still slightly leaning towards the idea that we should give extensions the tools they need, but that there should be a single content setting management - either chrome or the extension (we've even had some discussions around whether or not we could just get rid of the content settings in settings and publish and official extension that does it).  But if we can make them conditionally work together without introducing a ton more complexity, I'm open to that. :)