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 ...
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: Plug-ins (show other bugs)
: Trunk
: All All
: -- normal (vote)
: mozilla18
Assigned To: David Keeler [:keeler] (use needinfo?)
:
Mentors:
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:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
fixed
fixed


Attachments
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 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 David Keeler [:keeler] (use needinfo?) 2012-09-07 16:57:39 PDT
Created attachment 659409 [details] [diff] [review]
patch
Comment 2 Blair McBride [:Unfocused] (UNAVAILABLE) 2012-09-10 05:53:36 PDT
Comment on attachment 659409 [details] [diff] [review]
patch

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 David Keeler [:keeler] (use needinfo?) 2012-09-10 13:39:59 PDT
This ran green: https://tbpl.mozilla.org/?tree=Try&rev=49bef3992cf8
Marking checkin-needed.
Comment 5 Ryan VanderMeulen [:RyanVM] 2012-09-10 18:43:07 PDT
https://hg.mozilla.org/mozilla-central/rev/74d24d902ad6
Comment 6 David Keeler [:keeler] (use needinfo?) 2012-10-03 10:31:05 PDT
Comment on attachment 659409 [details] [diff] [review]
patch

[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 Alex Keybl [:akeybl] 2012-10-03 15:14:08 PDT
Comment on attachment 659409 [details] [diff] [review]
patch

[Triage Comment]
Good fix for a newly uplifted feature.
Comment 8 Ryan VanderMeulen [:RyanVM] 2012-10-05 18:56:36 PDT
https://hg.mozilla.org/releases/mozilla-aurora/rev/21dc87c86767

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