1007389 - Implement plugin whitelist, round 2

Status: RESOLVED FIXED

(Core Graveyard :: Plug-ins, defect)

Description

[Benjamin Smedberg]

+++ This bug was initially created as a clone of Bug #992995 +++

This is a rollup for four additional plugins that we are whitelisting:

* bug 981503 - McAfee Virtual Technician
* bug 989872 - Verimatrix ViewRightsWeb
* bug 987057 - McAfee SiteAdvisor Enterprise
* bug 985640 - F5 Networks SSLVPN plugin

QA for each plugin will be performed by the plugin vendor who submitted the whitelist request.

Comment 1

[Benjamin Smedberg]

Attachment: 1007389-whitelist2

Comment 2

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/585c5223dbe9

Comment 3

[Lukas Blakk [:lsblakk] use ?needinfo]

Time to uplift yet?

Comment 4

[Benjamin Smedberg]

Comment on attachment 8419046 [details] [diff] [review]
1007389-whitelist2

[Approval Request Comment]
Bug caused by (feature/regressing bug #): Plugin whitelisting
User impact if declined: these 4 plugins won't activate by default
Testing completed (on m-c, etc.): landed on m-c: two of the plugins are verified
Risk to taking this patch (and alternatives if risky): Very low risk
String or IDL/UUID changes made by this patch: None

Comment 5

[Bogdan Maris, Desktop QA]

It wasn't much to test here from our side, most of the plugins were not available for download. Did manage to install McAfee Virtual Technician but plugin was not present in the Addons Manager. We made an etherpad where we covered our testing: https://etherpad.mozilla.org/Plugin-Whitelist-2-32-0a1

Let me know if there is anything else we should cover here.

Comment 6

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/5853db2e8475
https://hg.mozilla.org/releases/mozilla-beta/rev/859a8098cd8d

Comment 7

[Liz Henry (:lizzard) (relman/hg->git project)]

benjamin, do you have contact info for the plugin vendors who are going to do the QA? Is that something that Mozilla QA should follow up on? Thanks!

Comment 8

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-b2g30_v1_4/rev/859a8098cd8d

Comment 9

[Benjamin Smedberg]

The contact information is in the whitelist bugs from comment 0. I really don't want Mozilla QA to be involved: we want to rely on vendor QA for this.

Comment 10

[Lukas Blakk [:lsblakk] use ?needinfo]

(In reply to Benjamin Smedberg  [:bsmedberg] from comment #9)
> The contact information is in the whitelist bugs from comment 0. I really
> don't want Mozilla QA to be involved: we want to rely on vendor QA for this.

Adding need-info on those contacts to check Firefox 30 (Beta) to verify this is working as expected.

Comment 11

[bhageerathi_bai]

McAfee SiteAdvisor Enterprise behavior on Firefox 30 (Beta): 

Scenario 1:
1. Have FF 29 with SiteAdvisor Enterprise installed on a client
2. Upgrade to FF 30 Beta

Actual:  SiteAdvisor Enterprise plugin goes "Ask to Activate" state and does not work until it is changed(to "Always Activate")

Expected: SiteAdvisor Enterprise plugin should be set to "Always Activate" by default.

Comment 12

[Lukas Blakk [:lsblakk] use ?needinfo]

Bsmedberg, is the expected result in comment #11 the expected behaviour of the whitelist functionality?

Comment 13

[Benjamin Smedberg]

No. Assuming no changed preferences or messing with the plugin notification menu, the plugin should inherit the default state from prefs.

I don't know why we're doing verification here instead of in the bugs where I asked for it already. That's confusing.

Comment 14

[bhageerathi_bai]

I am verifying based on the comment 10 ... "Adding need-info on those contacts to check Firefox 30 (Beta) to verify this is working as expected"

The scenario I have mentioned is mostly seen by all customers. I have not changed any preference setting of firefox before upgrading and see plugin is not inheriting the default state.
After upgrade, plugin state should remain same which was "Always activate"

Comment 15

[Lukas Blakk [:lsblakk] use ?needinfo]

(In reply to Benjamin Smedberg  [:bsmedberg] from comment #13)
> No. Assuming no changed preferences or messing with the plugin notification
> menu, the plugin should inherit the default state from prefs.
> 
> I don't know why we're doing verification here instead of in the bugs where
> I asked for it already. That's confusing.

Because we are not tracking each individual whitelist request, nor are they marked blocking this bug so this is the easiest place to confirm the tracked bug is actually fixed.

Comment 16

[Benjamin Smedberg]

bhageerathi, you'll need to do some more detailed testing, since you reported in bug 987057 that the whitelist was working.

In about:config, please check the prefs plugin.state.* in the old and new versions to see whether the pref "plugin.state.npmcffplg" is present and if it has a user value (is bold).

In an old Firefox where you haven't changed anything, the pref should not be present at all.
In a new Firefox where you haven't changed anything, the pref should be "2" and should not be bold.

Comment 17

[bhageerathi_bai]

Steps performed:
1. In the old version, FF29 > checked about:config|plugin.state.* :: "plugin.state.npmcffplg was NOT present
2. Upgraded FF to ver 30 beta 
3. In the new version FF30 Beta > checked about:config|plugin.state.*:: "plugin.state.npmcffplg is present and the pref value is "2"
Verified on WIn 7 and XP machines.
Please check the attachment.

Comment 18

[bhageerathi_bai]

Attachment: plugin_state.JPG

Attaching the pref value snapshot

Comment 19

[Benjamin Smedberg]

Those are the expected pref values. Are you saying that the plugin is listed as "click to activate" in the addon manager even though the pref value is "2"? If so, please go to about:plugins and paste the information about the McAfee plugin into this bug.

Comment 20

[bhageerathi_bai]

No I am NOT saying plugin is listed as "click to activate" in the addon manager even though the pref value is "2"

what I mean is - Now the plugin is listed as "Always Activate" in the addon manager with pref value "2" even in the FF upgrade scenario.

This was not the case when I reported in comment 11. Not sure if the Beta builds have changed now.

Comment 21

[u279076]

Keeping verifyme on this bug until the need-info flags have been addressed.

Comment 22

[John Thomas [:Johnt]]

This appears to be an issue that Qanalyst is unable to verify. Marking QAExclude.