393316 - Need a method to distinguish blocklisted plugins from user disabled plugins

Status: RESOLVED WORKSFORME

(Core Graveyard :: Plug-ins, defect)

Description

[Robert Strong (they/them - no direct email)]

So we can reenable a plugin that is updated to a non-blocklisted version or removed from the blocklist.

Comment 1

[Robert Strong (they/them - no direct email)]

while still respecting a user disabled plugin

Comment 2

[Dave Townsend [:mossop]]

Without this I think if we update a blocked plugin to a non-blocked one we end with it disabled.

Comment 3

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Robert, would you be the right guy to fix this?

Comment 4

[Dave Townsend [:mossop]]

Looking at this and I'm not sure what extra is necessary here. The plugin can already be marked as blocklisted or disabled separately. What else is missing Rob?

Comment 5

[Robert Strong (they/them - no direct email)]

Jonas, I doubt I'll have the time to do this along with the work I need to finish up on the installers. 

Dave, this is the same problem we had way back with the EM in that the user can disable the plugin and the app can disable the plugin (e.g. blocklisting). We might be able to work around this with those two for now but I believe at the very least that a user would have to manually enable a plugin if it were removed from the blocklist since a plugin is set to disabled in the same way it is set to disabled by the user. I could be wrong in this assumption.

Comment 6

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

So what is needed here? Just more UI? If so this bug should be moved to some Firefox or toolkit component.

Comment 7

[Robert Strong (they/them - no direct email)]

What I discussed with mwu was having a separate bit from the current disabled bit that would also disable the plugin. For example, in the EM RDF datasource we have userDisabled and appDisabled to distiguish between whether an extension should be automatically enabled or left disabled. Before this was implemented there were significant user complaints about extensions not being reenabled when downgrading to a version of the app the extension was compatible with.

One example, if a plugin was blocklisted in version 4.x of an application but not in version 3.x of an application the user would have to manually re-enable to plugin when downgrading if there is no way to distinguish between it being user disabled vs. app disabled.

Comment 8

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Moving this back to blocking? as I'm not sure what needs to be done here. Is this really the component used for blocklisting type stuff?

Comment 9

[Robert Strong (they/them - no direct email)]

The disabled state for a plugin is stored in pluginreg.dat. What we need to be able to do is distinguish whether the plugin was disabled by the app or the user and enable / disable the plugin based on this. So, a plugin can be user disabled and app disabled at the same time. It really isn't specific to blocklisting though blocklisting would be the first and possibly the only consumer of app disabled for a plugin.

We could invent another datastore for this info which I am very loathe to do and mwu assured me that there is plenty of unused bits left in pluginreg.dat where the current disabled bit is stored.

Comment 10

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

It sounds like this is a blocker, but who should we assign it to?

Comment 11

[Dave Townsend [:mossop]]

I think I was unclear in my comment, looking at the plugin code we appear to have a blocklisted flag (NS_PLUGIN_FLAG_BLOCKLISTED) in the plugin code that is stored to pluginreg.dat already. I'm not an expert on the code but what we want appears to be in place already.

http://mxr.mozilla.org/seamonkey/source/modules/plugin/base/src/nsPluginHostImpl.cpp#1032

Comment 12

[Robert Strong (they/them - no direct email)]

It is entirely possible that mwu added it in a different bug before he left and didn't let me know.

Comment 13

[Dave Townsend [:mossop]]

Closing this as WFM. An appropriate flag appears to exist on the pluginhost, it is used by the blocklisting service. It appears to have been added by bug 330511.