Opt-in activation for plugins: Difference between revisions

Jump to navigation Jump to search
no edit summary
No edit summary
No edit summary
Line 18: Line 18:
}}
}}
{{FeaturePageBody
{{FeaturePageBody
|Feature open issues and risks=* How do we manage Mozilla-controlled click to play settings?  Deliver via our existing blocklist mechanism? (Potentially leverage severity 0 "warning-only" blocklist entries"?) A new system?
|Feature open issues and risks=* Adverse reactions between content plugin sniffing and click-to-play
** Requires more research
 
* Adverse reactions between content plugin sniffing and click-to-play
** Bsmedberg asks in bug 711552: "Are we exposing to the DOM that a particular plugin element (<object> or <embed> is user-disabled?) This seems important for websites that rely primarily on plugins (e.g. Pandora) so that they can show alternate UI (plugins are disabled, please click to play) instead of timing out and showing a generic "please install Flash" or "Song initialization timed out, please hit refresh" UI."
** Bsmedberg asks in bug 711552: "Are we exposing to the DOM that a particular plugin element (<object> or <embed> is user-disabled?) This seems important for websites that rely primarily on plugins (e.g. Pandora) so that they can show alternate UI (plugins are disabled, please click to play) instead of timing out and showing a generic "please install Flash" or "Song initialization timed out, please hit refresh" UI."
** Can content differentiate between "click to play" and "hard-disabled for security reasons"?
** Can content differentiate between "click to play" and "hard-disabled for security reasons"?
Line 98: Line 95:


When "click to play" plugins are found on a page, their start up will be delayed until a user performs interaction with the browser to enable the running of the plugin (as much as possible).
When "click to play" plugins are found on a page, their start up will be delayed until a user performs interaction with the browser to enable the running of the plugin (as much as possible).
To use the blocklist to make a plugin click-to-play, an entry must be added for that plugin as normal (as if it were being soft or hard-blocked). The "severity" field must be "0". A new field, "vulnerabilitystatus" must be "1" or "2". "1" corresponds to there being a known update to the plugin, and "2" corresponds to there not being an update. See [http://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/extensions/test/xpcshell/data/test_pluginBlocklistCtp.xml test_pluginBlocklistCtp.xml] and [http://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/extensions/test/xpcshell/test_pluginBlocklistCtp.js test_pluginBlocklistCtp.js] for examples.
|Feature ux design=Visible plugins will have a chrome-privileged overlay that users will click on to activate the plugin. Invisible (or barely visible) plugins will cause an infobar to appear to enable all plugins on the page.
|Feature ux design=Visible plugins will have a chrome-privileged overlay that users will click on to activate the plugin. Invisible (or barely visible) plugins will cause an infobar to appear to enable all plugins on the page.


Confirmed users
299

edits

Navigation menu