<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 3/25/2013 7:13 PM, Larissa Co wrote:<br>
</div>
<blockquote cite="mid:5150DA22.6060504@mozilla.com" type="cite">
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
Bsmedberg and I have been talking about some of the Java CtP
design ideas I put forth in: <a moz-do-not-send="true"
class="moz-txt-link-freetext"
href="http://people.mozilla.com/%7Elco/CtP/130318%20CtP%20concepts.pdf">http://people.mozilla.com/~lco/CtP/130318%20CtP%20concepts.pdf</a>
and we thought it would be valuable to move the conversation over
to this list. <br>
</blockquote>
We're getting close! Here are the decisions that I believe we made
at today's meeting. lco/keeler, please interject if you have an
alternate understanding ;-)<br>
<br>
* Known-insecure plugins will be blocked by default.<br>
* By default, the doorhanger will drop down automatically once per
site. This will not be repeated every time you restart Firefox.<br>
* Clicking on the plugin content or the doorhanger icon will reshow
the same doorhanger.<br>
* The doorhanger will expose two options to the user:<br>
** The default option will allow the plugin to run on the current
site for a short while. As long as the user keeps actively using a
site, they will not see any more prompts about the plugin. The
permission will expire after 60 minutes away from the website, or
when the user closes the browser.<br>
** The secondary option will allow the plugin on that site and not
be prompted. However, if the user does not visit the site for 90
days, or if the site stops using the plugin for 90 days, the
permission will reset.<br>
* There will be no option to allow an insecure plugin for all sites,
either in the doorhanger or in the addons manager.<br>
<br>
For plugins in general, we are going to provide the same general
options as for insecure plugins, with the following modifications:<br>
* Users must opt in to plugins by default. The UI will be lighter
and less intimidating than for known-insecure plugins.<br>
* The default option will be "allow for site".<br>
* Users can completely enable a plugin (for all sites) using the
addons manager. Depending on the UX design, this may also be exposed
as an option in the doorhanger.<br>
<br>
We do not intend to expose a UI option for single-click activation
of plugins the way the current "plugins.click_to_play" UI works.
This will remain a feature available to power users via hidden prefs
or extensions such as flashblock/adblock plus.<br>
<br>
Larissa and Stephen are going to decide this coming week between the
two doorhanger designs: either a dropdown menu, or two side-by-side
buttons. They will also propose strings for the two options. I am
hoping that we can have a complete design by the end of next week,
and can get the final visuals in the following few weeks.<br>
<br>
At this point, the only significant change in Firefox 22 is bug
832481: blocklisted plugins must be activated from the doorhanger.
This change was made to keep the blocklist effective in the face of
clickjacking. The rest of the changes here will hopefully land in
the Firefox 23 cycle. I think we should probably also delay landing
bug 549697 into the the Firefox 23 cycle as well, because the
meaning of the "click-to-play" state is going to change.<br>
<br>
--BDS<br>
<br>
</body>
</html>