Status of click-to-play plugins in Firefox 24/26

Gavin Sharp gavin at mozilla.com
Mon Nov 4 18:05:36 UTC 2013


> There has not been a clear decision on which of these options to
> implement. I'm also a little worried about having to invent new button
> styling to implement shorlander's UI mockups, since I don't think there
> are already button styles for the blue/highlighted options. What I
> propose that I implement something like shorlander's mockup with the
> followup changes:
> 
> * use standard OS styles for all the buttons
> * use the "Continue Blocking" and "More Options" buttons for both the
> insecure-plugin and unknown-plugin cases
> * Because we don't have a "More Options" string, just use "Options"

This sounds good to me, and seems consistent with what Madhava, Chad and I discussed earlier this week. Let's go with this.

(The close button on the left rather than the right seems like an odd change from other notification bars, was that an intentional design decision?)

For the icon, can you use error-16.png (or warning-16.png)?

Gavin


----- Original Message -----
> From: "Benjamin Smedberg" <benjamin at smedbergs.us>
> To: "Firefox Dev" <firefox-dev at mozilla.org>
> Cc: "paul silaghi" <paul.silaghi at softvision.ro>, "Stephen Horlander" <shorlander at mozilla.com>, "Larissa Co"
> <lco at mozilla.com>, "release-drivers" <release-drivers at mozilla.org>, "Madhava Enros" <menros at mozilla.com>
> Sent: Monday, November 4, 2013 7:58:56 AM
> Subject: Re: Status of click-to-play plugins in Firefox 24/26
> 
> Here is the current status of this feature:
> 
> == BUG FIXES ==
> 
> * Doorhanger icon disappearing when the page navigates a subframe
> (testcase  https://www.mojebanka.cz/) - bug 915951 fixed for Saturday's
> nightly and already has aurora/beta approval already
> * UI changes to make the in-content UI look more clickable: bug 932446,
> landed for today's nightly and I just requested aurora/beta uplift
> * Plugins removed immediately after being added and scripted don't
> trigger the notification - bug 745187 landed for today's nightly and I
> just requested aurora/beta uplift
> * Bug 932786 - after you choose to enable or disable a plugin via the
> notification, the notification doesn't update the UI to the new state -
> minor regression from bug 926605, landed for today's nightly and
> aurora/beta uplift requested
> 
> With this series of patches, all sites that I know about now show the
> notification icon and work correctly when the user enables plugins via
> the notification. A reload may be required for a few sites.
> 
> I'm going to post the approval details here, rather than spread across
> the bugs:
> 
> Testing completed: manual testing on
> http://benjamin.smedbergs.us/tests/ctptests/ as well as the sites which
> were broken. In the 4-Nov nightly for general testing. Paul Silaghi has
> been doing focused verifications as well.
> Risk assessment: the patches here are unlikely to affect anything other
> than click-to-activate plugins. They are all fairly small, but together
> there is some risk of regression in this feature. I believe we should
> take them in early betas and do focused testing and feedback analysis.
> No string or IDL changes.
> 
> == DISCOVERABILITY ==
> 
> We have decided to implement a notification bar to make hidden plugins
> explicitly visible, but the exact interaction and visual appearance of
> the notification is not yet resolved. Here are the
> wireframes/screenshots that were being discussed in IRC:
> 
> shorlander: http://cl.ly/image/3R0w221e3z1e/o
> 
> In this design, the "More Options" button would open the notification
> panel. The "Continue Blocking" button would permanently dismiss the
> notification bar for that site. Clicking the "X" would close the
> notification for the current page but it would reopen if other pages on
> the site use hidden plugins.
> 
> I would also need the no-entry icon in a 16x16 size.
> 
> lco:
> http://cl.ly/image/2Z3N1a2L3L3O
> http://cl.ly/image/443N1d0y2h0a
> 
> my own prototype:
> http://benjamin.smedbergs.us/tests/ctptests/screenshots/new/ctp-infobar-mock.png
> 
> I'm a little unhappy with the options that have a one-click Allow
> button. In general, I think we should require two clicks to activate all
> plugins.
> 
> There has not been a clear decision on which of these options to
> implement. I'm also a little worried about having to invent new button
> styling to implement shorlander's UI mockups, since I don't think there
> are already button styles for the blue/highlighted options. What I
> propose that I implement something like shorlander's mockup with the
> followup changes:
> 
> * use standard OS styles for all the buttons
> * use the "Continue Blocking" and "More Options" buttons for both the
> insecure-plugin and unknown-plugin cases
> * Because we don't have a "More Options" string, just use "Options"
> 
> I am also tracking the following issues, but I do not consider them
> release blockers:
> 
> * https://bugzilla.mozilla.org/show_bug.cgi?id=853973 - Can't click on
> the click-to-play UI if the site overlays the element with an element in
> another subtree. This primarily affects the apple movie trailers site.
> We may be able to work around this by using the hidden-plugin
> doorhanger. We cannot fix this with z-ordering because of the way DOM
> subtrees and z-ordering work.
> * https://bugzilla.mozilla.org/show_bug.cgi?id=801406 - Click to play
> doesn't work for pages with generated POST data (primarily a problem for
> PDF docs and acrobat).
> * https://bugzilla.mozilla.org/show_bug.cgi?id=883404 - Disable running
> plugins on the page when the user blocks them. Right now the option only
> takes effect on reload, which can be slightly confusing.
> 
> --BDS
> 
> _______________________________________________
> release-drivers mailing list
> release-drivers at mozilla.org
> https://mail.mozilla.org/listinfo/release-drivers
> 



More information about the firefox-dev mailing list