Confirm
197
edits
Changes
no edit summary
#* '''Info bar / door hanger will show up asking if the user wants to enable the plugin, showing user-friendly name of plugin if possible.'''
# A web page has multiple instances of a plugin that requires click to play
#* '''Clicking to play one instance of the plugin will enable that instance and all hidden instances of the same plugin. Other visible instances of the plugin will not be enabled until explicitly clicked. Plugins of other types are not activated'''Possible future use cases (ideas that need research):
# User has a plugin that is up-to-date and used within the last 30 days:
#* '''Plugin will run automatically.'''
We are not currently differentiating between an SSL site containing plugin content and an HTTP site containing plugin content. We are differentiating per domain and not per scheme or port.
|Feature functional spec=See Users and Use Cases 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). |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 implementation plan=Phase 1:
Users can turn on a preference to require click to play for all plugins globally
Phase 4: Explore User and Use Cases 8-10. This needs more research. Can we leverage user behavior to define a heuristic of when a plugin should be click to play?
|Feature implementation notes=Meta bug for the work is {{bug|738698}}
