Unblocklisted plugin should be set to enable on startup

VERIFIED FIXED in mozilla1.9beta5

Status

()

Core
Plug-ins
P2
normal
VERIFIED FIXED
10 years ago
10 years ago

People

(Reporter: tchung, Assigned: mossop)

Tracking

Trunk
mozilla1.9beta5
Points:
---
Dependency tree / graph
Bug Flags:
wanted-next +
blocking1.9 +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

10 years ago
User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b4pre) Gecko/2008022504 Minefield/3.0b4pre
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b4pre) Gecko/2008022504 Minefield/3.0b4pre

updating a unblocklisted plugin version from a blocklisted plugin should be set to "enable" on restart.  It currently is still enabled, and needs to be manually enabled through addons manager

** See screenshot

Reproducible: Always

Steps to Reproduce:
1. Load clean nightly trunk build.  
2. set plugin blocklist settings called out at:
https://bugzilla.mozilla.org/show_bug.cgi?id=391731#c3
3. Install blocklisted plugin  (eg. Flash 7
4. Restart browser, and go to URL
5. Verify flash7 plugin is blocked, and flash website fails to load (eg. youtube)
6. Now install over a supported plugin version that is not blocklisted (eg. Flash 8)
7. Restart browser, and verify the supported unblocklisted plugin, is set to "Disable".   User needs to go to addons Manager > Plugins Tab and Enable by hand.  This needs to be "enabled" upon restart.

Actual Results:  
Unblocklisted plugin should be Enabled upon restart automatically 

Expected Results:  
Unblocklisted plugin needs to be manually Enabled after restart.
(Reporter)

Comment 1

10 years ago
Created attachment 305688 [details]
Unblocklisted Plugin Disabled screenshot
(Reporter)

Updated

10 years ago
Blocks: 391731
Flags: blocking-firefox3?
Version: unspecified → Trunk
(Assignee)

Updated

10 years ago
Component: Extension/Theme Manager → Plug-ins
Flags: blocking-firefox3?
Product: Firefox → Core
QA Contact: extension.manager → plugins
(Assignee)

Updated

10 years ago
Flags: blocking1.9?
(Assignee)

Comment 2

10 years ago
When a plugin is marked as blocklisted it is also getting disabled, but when unblocklisted it isn't getting re-enabled. This could be as simple as not disabling at all, but I need to check through to see if we are correctly checking for blocklisted in the right places.

http://mxr.mozilla.org/seamonkey/source/modules/plugin/base/src/nsPluginHostImpl.cpp#1038
(Assignee)

Comment 3

10 years ago
This is I think not totally critical, but should be a fairly easy fix that I can tackle.
Whiteboard: [swag 0.5d]

Updated

10 years ago
Flags: tracking1.9? → blocking1.9?
Doesn't seem like a blocker. Why would we ever unblocklist a plugin? The only thing I could think of is if we accidentally blocklist something, but we'd never do that since we're perfect :)
Flags: wanted1.9.0.x?
Flags: wanted-next+
Flags: blocking1.9?
Flags: blocking1.9-
(Assignee)

Comment 5

10 years ago
(In reply to comment #4)
> Doesn't seem like a blocker. Why would we ever unblocklist a plugin? The only
> thing I could think of is if we accidentally blocklist something, but we'd
> never do that since we're perfect :)

I'm re-requesting blocking because I think you've misunderstood the problem. This is not about unblocklisting an already blocklisted plugin, it is about installing a newer safe version of a plugin on top of your old unsafe plugin. So imagine we blocklisted just Flash 8, user finds Flash 8 is blocked, installs Flash 9 and with this bug would then still need to go to tools - addons to re-enable the plugin.
Flags: blocking1.9- → blocking1.9?
I see. Still not the end of the world, but seems like it would be very nice to have fixed before release.
Flags: blocking1.9? → blocking1.9+
Priority: -- → P2
(Assignee)

Comment 7

10 years ago
Going to need this to fix bug 419552 without too much churn
Assignee: nobody → dtownsend
Blocks: 419552
(Assignee)

Comment 8

10 years ago
Created attachment 309533 [details] [diff] [review]
patch rev 1

The problem here is that we use 2 flags to store a plugin's state. 1 holds whether the plugin is blocklisted. The other holds whether the plugin is not blocklisted and is not disabled by the user.

The majority of this patch changes the meaning of the flag NS_PLUGIN_FLAG_ENABLED to mean "the user has not disabled this plugin". Added to nsPluginTag is a simple method IsEnabled() which tests that and the blocklist flag, the result of which is the same as the old flag used to mean. So mostly it replaces checks for the flag to checks for IsEnabled.

A couple of occasions I had to stop registering a plugin's mimetypes with the category manager because it assumed that a plugin from the cache was always enabled which is not the case any longer.

Added in is the work for bug 419552. Much of that is fixed by the above however there are some remaining issues because in a lot of places we use the enable_java pref to determine if java is enabled, and that ignores the blocklist.

So I've dropped the use of the pref in nsIJVMManager preferring instead to just query the plugin host for whether a java plugin is installed and enabled. It watches the jvm mimetype in the category manager to know when the plugin is enabled and disabled. This ends up also fixing bug 401110 as well as an unfiled bug on live connect failing when no jvm is installed.
Attachment #309533 - Flags: superreview?(jst)
Attachment #309533 - Flags: review?(jst)
(Assignee)

Updated

10 years ago
Status: NEW → ASSIGNED
Whiteboard: [swag 0.5d] → [has patch]
Comment on attachment 309533 [details] [diff] [review]
patch rev 1

Looks good, assuming the UI pref for enabling/disabling Java still works, which it looks like it would.
Attachment #309533 - Flags: superreview?(jst)
Attachment #309533 - Flags: superreview+
Attachment #309533 - Flags: review?(jst)
Attachment #309533 - Flags: review+
(Assignee)

Comment 10

10 years ago
Created attachment 310212 [details] [diff] [review]
patch checked in

Double checked that and it does, this is the same patch apart from a little bitrotting.
Attachment #309533 - Attachment is obsolete: true
Attachment #310212 - Flags: superreview+
Attachment #310212 - Flags: review+
(Assignee)

Comment 11

10 years ago
Checking in dom/src/base/nsGlobalWindow.cpp;
/cvsroot/mozilla/dom/src/base/nsGlobalWindow.cpp,v  <--  nsGlobalWindow.cpp
new revision: 1.1003; previous revision: 1.1002
done
Checking in modules/oji/src/nsJVMManager.cpp;
/cvsroot/mozilla/modules/oji/src/nsJVMManager.cpp,v  <--  nsJVMManager.cpp
new revision: 1.83; previous revision: 1.82
done
Checking in toolkit/mozapps/extensions/content/extensions.js;
/cvsroot/mozilla/toolkit/mozapps/extensions/content/extensions.js,v  <--  extensions.js
new revision: 1.175; previous revision: 1.174
done
Checking in modules/plugin/base/src/nsPluginHostImpl.cpp;
/cvsroot/mozilla/modules/plugin/base/src/nsPluginHostImpl.cpp,v  <--  nsPluginHostImpl.cpp
new revision: 1.603; previous revision: 1.602
done
Checking in modules/plugin/base/src/nsPluginHostImpl.h;
/cvsroot/mozilla/modules/plugin/base/src/nsPluginHostImpl.h,v  <--  nsPluginHostImpl.h
new revision: 1.113; previous revision: 1.112
done
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago
Flags: wanted1.9.0.x?
Resolution: --- → FIXED
Whiteboard: [has patch]
Target Milestone: --- → mozilla1.9beta5
(Reporter)

Comment 12

10 years ago
Verified fix on Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9pre) Gecko/2008042106 Minefield/3.0pre.   reinstalling an unblocked plugin is now enabled on startup.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.