The desktop web runtime needs the ability to configure the underlying core to only allow versions of flash to run within the runtime. All other plugins are planned to not be allowed within the runtime, although we should be ready to evolve and change quickly if we discover later down the line that we need to enable other plugins. The implementation I heard discussed in today's apps meeting considered configuring a whitelist of the plugins that are allowed to run. This is needed for the first release of the desktop web runtime (Fx 15).

I can look into this, it shouldn't be very difficult

Nominating for k9o - this is needed for the desktop web runtime to only enable flash in the runtime.

jst, this has been called out as the correct implementation for bug 755554, can you confirm?

This adds plugin.allowed_types, which limits what MIME types plugins can claim (comma separated) Right now it does not completely suppress (mark invalid) plugins that claim no valid types -- they'll be in the plugin registry, but will not be associated with any types or suffixes. We could suppress these, but that would mean that modifying this pref would require deleting pluginreg.dat

Flagging for tracking FF 16 - we need this for desktop web runtime 1st release

Comment on attachment 638498 [details] [diff] [review] Implement plugin.allowed_types whitelist Note that the 'IsTypeInPrefList' helper duplicates some nsPluginTag::RegisterWithCategoryManager code, which goes away with a patch on bug 751237 (it just makes sense to land this first)

Comment on attachment 638498 [details] [diff] [review] Implement plugin.allowed_types whitelist >diff --git a/dom/plugins/base/nsPluginHost.cpp b/dom/plugins/base/nsPluginHost.cpp >+nsPluginHost::IsTypeWhitelisted(const char *aMimeType) >+{ >+ if (!Preferences::HasUserValue(kPrefWhitelist)) { >+ return true; This will mean that a default value of the preference won't be effective - isn't that what we need for bug 755554?

(In reply to :Gavin Sharp (use gavin@gavinsharp.com for email) from comment #7) > This will mean that a default value of the preference won't be effective - > isn't that what we need for bug 755554? Bah, I intended that the whitelist not be enforced if it was empty, but clearly HasUserValue is not going to work if we're giving it defaults.

Comment on attachment 640453 [details] [diff] [review] Followup, check if the preference has a value, not necessarily a user value Why not just put the pref check in IsTypeInPrefList() itself, since it's already reading the pref anyways?

(In reply to :Gavin Sharp (use gavin@gavinsharp.com for email) from comment #11) > Comment on attachment 640453 [details] [diff] [review] > Followup, check if the preference has a value, not necessarily a user value > > Why not just put the pref check in IsTypeInPrefList() itself, since it's > already reading the pref anyways? IsTypeInPrefList is a helper to deduplicate code between this and the category manager changes in bug 751237, where we don't want to return true if the pref is empty. I can change it to just move the GetString call out of the helper for simplicity

Should bugs be filed blocking this if we want to add other plugins to the whitelist? Silverlight for Netflix, for example.

(In reply to Reuben Morais [:reuben] from comment #16) > Should bugs be filed blocking this if we want to add other plugins to the > whitelist? Silverlight for Netflix, for example. Enabling the whitelist in webrt was done in bug 755554, so that may be a better target

Verified through testing of bug 755554 for Win 7, OS X 10.7, and Ubuntu 12.

It seems like this bug missed the daily check for updates and is the cause of https://bugzilla.mozilla.org/show_bug.cgi?id=768521?