This will use browserSetting [1] to manage which extension has control over the pref. This does not really belong in privacy so will go into the browserSettings API. According to the notes in [2], this would make use of the `permissions.default.flash` preference, which seems to allow the following values [3]: STATE_DISABLED = 0; STATE_CLICKTOPLAY = 1; STATE_ENABLED = 2; I don't think WebExtensions need access to the ClickToPlay state, so I suggest calling the setting browser.browserSettings.flashEnabled and making it a boolean where true == 2 and false == 0. [1] https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/privacy/BrowserSetting [2] https://docs.google.com/document/d/1HZiI-dqFATzLpmTtN1Bg6tD8y4N0Ne3D74LEWWgttOk/edit# [3] http://searchfox.org/mozilla-central/source/dom/plugins/base/nsIPluginTag.idl#15-17

This comment is from an email from Justin Dolske to the "Intent to Implement" thread: ------ If this also allows enabling the Flash plugin, it should specify how it interacts with a future where (A) Flash is disabled/CTP for security reasons (your version is vulnerable) or (B) Flash is disabled/CTP by default for everyone because that's the next step in reducing it's impact on the web.

(In reply to Justin Dolske from comment #1) > > If this also allows enabling the Flash plugin, it should specify how it > interacts with a future where (A) Flash is disabled/CTP for security > reasons (your version is vulnerable) or (B) Flash is disabled/CTP by > default for everyone because that's the next step in reducing it's impact > on the web. This is a good point. One possible way of addressing this would be to take advantage of the BrowserSetting implementation and only allow extensions to set flash to disabled (i.e., they can not set flash to enabled), and also allow them to clear that setting (effectively re-enabling flash). This would also cause flash to be re-enabled when the extension is disabled or removed. This still leaves the possibility of flash being enabled at a later date (e.g., when the extension is removed) at which point it should remain disabled (for the reasons stated above). Perhaps there is extra code that we can access to determine whether to re-enable flash when an extension clears the setting? Rob, do you have any thoughts about this?

Caitlin, can you please add this to the next design-decision-needed triage?

The specification of this needs to be adjusted. In Firefox 55 we are going to make click-to-activate the *default* state for Flash, and we don't in general want addons to flip it back to fully enabled for all domains. It would be quite valuable for addons (especially enterprise deployments) to prepopulate a list of sites which are allowed to use Flash. I really need to be consulted, as the plugins product lead, as this heads toward implementation.

(In reply to Benjamin Smedberg [:bsmedberg] from comment #4) > The specification of this needs to be adjusted. In Firefox 55 we are going > to make click-to-activate the *default* state for Flash, and we don't in > general want addons to flip it back to fully enabled for all domains. It > would be quite valuable for addons (especially enterprise deployments) to > prepopulate a list of sites which are allowed to use Flash. > > I really need to be consulted, as the plugins product lead, as this heads > toward implementation. If we use BrowserSetting as it currently stands, and if we only allow extensions to disable flash (and not enable flash), then, when an extension does disable flash and is subsequently disabled/uninstalled it will revert the setting back to what it was, which would be click-to-activate by default. As discussed in a separate email thread, if a user manually sets flash to "enabled", and then an extension sets it to disabled and is then subsequently disabled/uninstalled, the setting would revert back to "enabled" as that was the value before the extension tried to set it. In that case an extension is effectively setting flash to "enabled" globally, although it never intended to do so. Having said all that, it sounds like you are suggesting that allowing extensions to globally disable flash is not something that we want to do anyway, and that we really need to look at only allowing extensions to control the flash setting on a per-domain basis. Is that an accurate statement? If so then perhaps we need to WONTFIX this and open a separate bug (or morph this bug into one) about allowing extensions to control flash on a per-domain basis.

> Having said all that, it sounds like you are suggesting that allowing > extensions to globally disable flash is not something that we want to do On the contrary, I'm fine with extensions to globally *disable* Flash. What I'm concerned about is not allowing extensions to globally *enable* Flash. > If so then perhaps we need to WONTFIX this and open a separate bug (or morph > this bug into one) about allowing extensions to control flash on a > per-domain basis. This bug about globally disabling is fine. I do think that another bug about allowing extension to enable on a per-domain basis is appropriate but have no particular insight into how high a priority it should be. I know enterprises want that sort of thing.

(In reply to Benjamin Smedberg [:bsmedberg] from comment #6) > > Having said all that, it sounds like you are suggesting that allowing > > extensions to globally disable flash is not something that we want to do > > On the contrary, I'm fine with extensions to globally *disable* Flash. What > I'm concerned about is not allowing extensions to globally *enable* Flash. Thanks for the clarification. Just to be totally clear, if we implement this, and allow extensions to globally disable flash, the following scenario is possible: 1. A user manually enables flash globally (e.g., via about:config). 2. An extension disables flash globally (and when doing so records the fact that flash was globally enabled prior to that point). 3. The user uninstalls the extension, which would revert the setting back to flash being enabled globally. Is that considered acceptable? > > > If so then perhaps we need to WONTFIX this and open a separate bug (or morph > > this bug into one) about allowing extensions to control flash on a > > per-domain basis. > > This bug about globally disabling is fine. I do think that another bug about > allowing extension to enable on a per-domain basis is appropriate but have > no particular insight into how high a priority it should be. I know > enterprises want that sort of thing. I think we will just leave that unfiled for now, and wait to see if it is requested.

> 1. A user manually enables flash globally (e.g., via about:config). This would be via the addon manager UI. > 2. An extension disables flash globally (and when doing so records the fact > that flash was globally enabled prior to that point). > 3. The user uninstalls the extension, which would revert the setting back to > flash being enabled globally. > > Is that considered acceptable? Yes.

Hi all, this has been added to the agenda for the May 23 WebExtension APIs triage meeting. Benjamin, would you be able to join us? Wiki: https://wiki.mozilla.org/Add-ons/Contribute/Triage Agenda: https://docs.google.com/document/d/1-j08Zo4sbwAuRZndNNtdIRlDM8TblddDA-PAeRgYMWU/edit#

(In reply to Benjamin Smedberg [:bsmedberg] from comment #8) > > 1. A user manually enables flash globally (e.g., via about:config). > > This would be via the addon manager UI. Can it not also be done by setting the permissions.default.flash preference to 2 (STATE_ENABLED)?

It's `plugin.state.flash`: and yes you could set it manually, but the point is that there is exposed UI for this setting, it's not just something that advanced users flip via about:config

I cannot join the triage meeting due to conflicts.

Thanks for clarifying what the pref is. Somehow I documented it as permissions.default.flash in this bug but yes, it is plugin.state.flash.

To reiterate bsmedberg, the extension preferences store module was specifically designed for the case of preferences that are not exposed outside of about:config. I agree that using that module to manipulate a preference that users can easily toggle from about:preferences would be a disaster.

Based on the concerns raised, in particular comment 14, we are not going to proceed with this.