832445 - Page Info -> Permissions doesn't show plugin permissions if plugins.click_to_play is false

Status: RESOLVED WONTFIX

(Firefox :: Page Info Window, defect)

Description

[Dana Keeler (she/her) [:keeler]]

This means users can't modify permissions for click-to-play blocklisted plugins on a per-site basis. The only way to undo an accidental "always-" or "never activate for this site" action is to clear all site preferences (in clear recent history).
The slight wrinkle is that in 20, bug 746374 landed, which will necessitate a more fundamental re-working of the plugins section of Page Info -> Permissions. This will be handled in bug 821892.

Comment 1

[Dana Keeler (she/her) [:keeler]]

Attachment: patch

Comment 2

[Jared Wein [:jaws] (please needinfo? me)]

Comment on attachment 704026 [details] [diff] [review]
patch

Review of attachment 704026 [details] [diff] [review]:
-----------------------------------------------------------------

::: browser/base/content/pageinfo/permissions.js
@@ +113,5 @@
>  
> +function haveCTPBlocklistedPlugin() {
> +  var blocklist = Components.classes["@mozilla.org/extensions/blocklist;1"]
> +                            .getService(Components.interfaces.nsIBlocklistService);
> +  var pluginHost = Components.classes["@mozilla.org/plugin/host;1"]

Please use |let| for new code.

@@ +116,5 @@
> +                            .getService(Components.interfaces.nsIBlocklistService);
> +  var pluginHost = Components.classes["@mozilla.org/plugin/host;1"]
> +                             .getService(Components.interfaces.nsIPluginHost);
> +  var pluginTags = pluginHost.getPluginTags();
> +  for (var tag of pluginTags) {

This can be:
return pluginTags.some(function(tag) { ... });
right?

@@ +129,4 @@
>  function initRow(aPartId)
>  {
> +  if (aPartId == "plugins" && !gPrefs.getBoolPref("plugins.click_to_play") &&
> +      !haveCTPBlocklistedPlugin())

Should we just always show this row and just use the plugins.click_to_play pref to determine what the default value for the permission is?

Comment 3

[Alex Keybl [:akeybl]]

(In reply to David Keeler from comment #0)
> This means users can't modify permissions for click-to-play blocklisted
> plugins on a per-site basis. The only way to undo an accidental "always-" or
> "never activate for this site" action is to clear all site preferences (in
> clear recent history).
> The slight wrinkle is that in 20, bug 746374 landed, which will necessitate
> a more fundamental re-working of the plugins section of Page Info ->
> Permissions. This will be handled in bug 821892.

Can we prepare an add-on of some sort that clears the plugin permissions specifically, for vending on SUMO?

We'll try to get a fix in for FF19 in the meantime.

Comment 4

[Dana Keeler (she/her) [:keeler]]

Attachment: patch v2

Updated patch, with a test (note about that: I used 'let' where I could, but in some cases I used 'var' to not mix let and var and to change as little as possible).

I think it's worth conditionally showing the plugin permission row, because if the user doesn't have any vulnerable plugins and also hasn't turned on click-to-play, that row has no meaning, so it should be hidden.

Also, just so we're all on the same page: this patch is only relevant to beta (19). Aurora (20) and central (21+) are going to need what's going on in bug 821892.

Comment 5

[Dana Keeler (she/her) [:keeler]]

Attachment: addon

Here's a little addon I made that basically unhides the plugin permission row.

Comment 6

[bhavana bajaj [:bajaj]]

(In reply to David Keeler (:keeler) from comment #5)
> Created attachment 705154 [details]
> addon
> 
> Here's a little addon I made that basically unhides the plugin permission
> row.

Thanks for your help here David, passing this on to support .

Comment 7

[Jared Wein [:jaws] (please needinfo? me)]

Comment on attachment 705153 [details] [diff] [review]
patch v2

Review of attachment 705153 [details] [diff] [review]:
-----------------------------------------------------------------

This looks fine, but you'll need to update about:permissions for this too.

Comment 8

[Dana Keeler (she/her) [:keeler]]

My understanding is that about:permissions hasn't been officially released and is still under development. Additionally, the fix isn't as simple there, due to about:permissions having both a global setting case and a per-site case, whereas Page Info -> Permissions is just per-site. So, given that not many people know about it or use it, and given that much more comprehensive changes are coming in bug 775857 (hopefully landing in FF20, but we'll see), I'm inclined to leave about:permissions as it is for now.

Comment 9

[Dana Keeler (she/her) [:keeler]]

... and those flags got reset somehow. This keeps happening to me. Is it something I'm doing wrong? I'm not touching those flags when I comment...

Comment 10

[:Gavin Sharp [email: [e-mail]]]

If you're reloading bugs, you need to use Shift+Reload to also reset form state (otherwise you may accidentally preserve the flag-unset state if the flag was set while you had the bug open, or vice-versa).

Comment 11

[Alex Keybl [:akeybl]]

(In reply to David Keeler (:keeler) from comment #5)
> Created attachment 705154 [details]
> addon
> 
> Here's a little addon I made that basically unhides the plugin permission
> row.

As a heads up, we've provided this add-on to SUMO so that they can aid users who run into this issue. Wontfixing for FF19, but let's try to get a fix in for FF20.

Comment 12

[Dana Keeler (she/her) [:keeler]]

This isn't applicable to FF >= 20 (see bug 746374, bug 821892), so I guess this whole bug is WONTFIX.