Last Comment Bug 789620 - click-to-play: a plugin made click-to-play by the blocklist won't go back to normal if unblocked
: click-to-play: a plugin made click-to-play by the blocklist won't go back to ...
Product: Core
Classification: Components
Component: Plug-ins (show other bugs)
: Trunk
: All All
-- normal (vote)
: mozilla18
Assigned To: David Keeler [:keeler] (use needinfo?)
: Benjamin Smedberg [:bsmedberg]
Depends on:
Blocks: click-to-play
  Show dependency treegraph
Reported: 2012-09-07 16:54 PDT by David Keeler [:keeler] (use needinfo?)
Modified: 2012-10-05 18:56 PDT (History)
4 users (show)
ryanvm: in‑testsuite+
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

patch (7.13 KB, patch)
2012-09-07 16:57 PDT, David Keeler [:keeler] (use needinfo?)
blair: review+
akeybl: approval‑mozilla‑aurora+
john: checkin+
Details | Diff | Splinter Review

Description User image David Keeler [:keeler] (use needinfo?) 2012-09-07 16:54:24 PDT
So, it turns out if we were to blocklist a plugin but later undo that block, the plugin would stay click-to-play.
Comment 1 User image David Keeler [:keeler] (use needinfo?) 2012-09-07 16:57:39 PDT
Created attachment 659409 [details] [diff] [review]
Comment 2 User image Blair McBride [:Unfocused] (UNAVAILABLE) 2012-09-10 05:53:36 PDT
Comment on attachment 659409 [details] [diff] [review]

Review of attachment 659409 [details] [diff] [review]:

::: toolkit/mozapps/extensions/nsBlocklistService.js
@@ +970,5 @@
>          plugin.blocklisted = state == Ci.nsIBlocklistService.STATE_BLOCKED;
>          if (state == Ci.nsIBlocklistService.STATE_VULNERABLE_UPDATE_AVAILABLE ||
>              state == Ci.nsIBlocklistService.STATE_VULNERABLE_NO_UPDATE)
>            plugin.clicktoplay = true;
> +        // turn off clicktoplay if it was previously set by the blocklist

Hmm, just realized this is going to be a pain when we expose UI for click-to-play for individual plugins (bug 549697), since this will undo the user's choice. Before we get that UI, I think we'll have to separate out blocklist-setting and user-setting for clicktoplay. Shouldn't be too painful - change usage here to .blocklistClicktoplay, add a .userClicktoplay, and make .clicktoplay only an accessor property whose value is based on those two.
Comment 3 User image David Keeler [:keeler] (use needinfo?) 2012-09-10 13:39:59 PDT
This ran green:
Marking checkin-needed.
Comment 5 User image Ryan VanderMeulen [:RyanVM] 2012-09-10 18:43:07 PDT
Comment 6 User image David Keeler [:keeler] (use needinfo?) 2012-10-03 10:31:05 PDT
Comment on attachment 659409 [details] [diff] [review]

[Approval Request Comment]
Bug caused by (feature/regressing bug #): blocklist/click-to-play plugins (bug 760625)
User impact if declined: if a plugin is click-to-play-blocklisted and then removed from the blocklist, it will continue to be a click-to-play plugin (with no UI to make it go back to normal)
Testing completed (on m-c, etc.): tested on m-c, been on nightly for a few weeks
Risk to taking this patch (and alternatives if risky): no particular risk
String or UUID changes made by this patch: none
Comment 7 User image Alex Keybl [:akeybl] 2012-10-03 15:14:08 PDT
Comment on attachment 659409 [details] [diff] [review]

[Triage Comment]
Good fix for a newly uplifted feature.
Comment 8 User image Ryan VanderMeulen [:RyanVM] 2012-10-05 18:56:36 PDT

Note You need to log in before you can comment on or make changes to this bug.