Last Comment Bug 523133 - Soft blocked plugin not showing warning and info link in Add-ons Manager (1.9.1 only)
: Soft blocked plugin not showing warning and info link in Add-ons Manager (1.9...
Status: VERIFIED FIXED
[mozmill-test-needed]
:
Product: Toolkit
Classification: Components
Component: Add-ons Manager (show other bugs)
: 1.9.1 Branch
: All All
: -- major (vote)
: ---
Assigned To: Dave Townsend [:mossop]
:
Mentors:
Depends on: 455906 514327
Blocks: 522975
  Show dependency treegraph
 
Reported: 2009-10-19 10:08 PDT by Dave Garrett
Modified: 2011-04-01 04:27 PDT (History)
10 users (show)
dveditz: wanted1.9.0.x-
hskupin: in‑litmus-
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
unaffected
.6+
.6-fixed


Attachments
warning and link shown correctly (Namoroka on WinXP) (26.57 KB, image/png)
2009-10-19 10:08 PDT, Dave Garrett
no flags Details
patch rev 1 (4.95 KB, patch)
2009-10-19 11:18 PDT, Dave Townsend [:mossop]
robert.strong.bugs: review+
dveditz: approval1.9.1.6+
Details | Diff | Splinter Review

Description Dave Garrett 2009-10-19 10:08:43 PDT
Created attachment 407052 [details]
warning and link shown correctly (Namoroka on WinXP)

1) New profile in latest Shiretoko or stable Firefox 3.5, with the Flash plugin installed.
2) In about:config, set extensions.blocklist.url to https://bug455906.bugzilla.mozilla.org/attachment.cgi?id=346066
3) Force a blocklist update. Can be done by executing the following in the Error Console's code line: Components.classes['@mozilla.org/extensions/blocklist;1'].getService(Components.interfaces.nsITimerCallback).notify(null)
4) The blocklist window should now come up to tell you that Shockwave Flash is soft blocked, with the appropriate option to override. (the test list has other items not relevant to this test here) Allow it to be disabled and click the restart button.
5) When it comes back, go to the Add-ons Manager plugin pane. Note the Flash entry is now disabled, however it is shown the same as any other disabled plugin.
6) Exit and load up the same profile in latest Namoroka or Minefield. Check the entry in the Add-ons Manager again. This time it has the expected "Known to cause security or stability issues." warning label and "More Information" link. (screenshot attached)

If you instead opt to not disable in step 4, no change is observable in step 5, however the line will still show correctly in step 6. You can also try Namoroka first then switch to Shiretoko or use separate profiles; 1.9.1 branch doesn't seem to be able to show it in any case. This feature seems to work fine for soft blocked extensions, however.

Tested on both Windows XP and Linux. Note that 3.6a1 doesn't show the expected line; latest nightly is required for it to work correctly.
Comment 1 Dave Townsend [:mossop] 2009-10-19 11:02:39 PDT
I have a simple fix in progress for this, would like to block the next
available 1.9.1 release on this.
Comment 2 Dave Townsend [:mossop] 2009-10-19 11:18:05 PDT
Created attachment 407063 [details] [diff] [review]
patch rev 1

This is a backport of a few hunks of the patch in bug 514327 which properly checks the softblock state of plugins. Trying to work out if it is possible to test this automatically.
Comment 3 Tony Chung [:tchung] 2009-10-19 11:26:34 PDT
dave, if it cant be automated, please flag in-litmus? so we can get a manual test added into litmus.
Comment 4 Daniel Veditz [:dveditz] 2009-10-21 15:27:15 PDT
Comment on attachment 407063 [details] [diff] [review]
patch rev 1

Please request approval1.9.1.5? after you get reviews.
Comment 5 Robert Strong [:rstrong] (use needinfo to contact me) 2009-10-23 21:22:38 PDT
Comment on attachment 407063 [details] [diff] [review]
patch rev 1

Looks good. Could you also update trunk with
const nsIBlocklistService    = Components.interfaces.nsIBlocklistService;

and replace Components.interfaces.nsIBlocklistService with BlocklistService?
Comment 6 Dave Townsend [:mossop] 2009-10-27 15:25:22 PDT
I don't think we can automate the testing here, we'll need a litmus test. The steps in comment 0 can provide a base.
Comment 7 Dave Townsend [:mossop] 2009-10-27 15:25:35 PDT
(In reply to comment #5)
> (From update of attachment 407063 [details] [diff] [review])
> Looks good. Could you also update trunk with
> const nsIBlocklistService    = Components.interfaces.nsIBlocklistService;
> 
> and replace Components.interfaces.nsIBlocklistService with BlocklistService?

Trunk already has this
Comment 8 Dave Garrett 2009-10-27 18:34:51 PDT
It might be nice to cover both the plugin and extension case of this in the litmus test, if possible.
Comment 9 Daniel Veditz [:dveditz] 2009-10-30 13:52:49 PDT
Comment on attachment 407063 [details] [diff] [review]
patch rev 1

Approved for 1.9.1.5, a=dveditz for release-drivers
Comment 10 Dave Townsend [:mossop] 2009-10-30 14:01:52 PDT
Looks like I accidentally had this patch already applied in my 1.9.1 tree when I landed bug 372980 so this has actually already landed in http://hg.mozilla.org/releases/mozilla-1.9.1/rev/2f9a687a93f1. I'll try to avoid this in the future.
Comment 11 Henrik Skupin (:whimboo) 2011-02-11 19:10:01 PST
Verified fixed with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.16pre) Gecko/20101105 Shiretoko/3.5.16pre

That would be a perfect test for Mozmill.
Comment 12 Henrik Skupin (:whimboo) 2011-04-01 04:27:38 PDT
The 1.9.1 branch will be abandoned soon so I will not add a Litmus test for it. In general the following test should be enough because we have a couple of automated tests meanwhile: https://litmus.mozilla.org/show_test.cgi?id=15309

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