Closed Bug 1007389 Opened 8 years ago Closed 8 years ago
Implement plugin whitelist, round 2
+++ 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.
Summary: Implement plugin whitelist → Implement plugin whitelist, round 2
Attachment #8419046 - Flags: review?(georg.fritzsche) → review+
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla32
Time to uplift yet?
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
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.
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!
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.
(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.
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.
Bsmedberg, is the expected result in comment #11 the expected behaviour of the whitelist functionality?
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.
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"
(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.
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.
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.
Attaching the pref value snapshot
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.
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.
Keeping verifyme on this bug until the need-info flags have been addressed.
This appears to be an issue that Qanalyst is unable to verify. Marking QAExclude.
Whiteboard: p=2 → p=2, QAExclude
QA Whiteboard: QAExclude
Whiteboard: p=2, QAExclude → p=2
You need to log in before you can comment on or make changes to this bug.