Status

No longer under consideration (dropped 3/23/2012) due to objections.

Contributors

• Last modified: March 23, 2012
• Authors: Rudi Sherry (Adobe Systems)
• Contributors:

Overview

Currently there are no mechanisms available for browser plugins to dynamically decide to disable themselves from being used, and more specifically to have the browser act like the plugin didn't exist.

One reason for this is that the plugin has its own UI for disabling, or has certain contexts in which it is unable to run. In these cases it is best to have the browser use its default mechanism for handling that appropriate mime type, rather than show a "plugin error" or a blank page.

Another reason, especially on the mac, is that all the browsers look in the same places, in the same way, for plugins to support mime types. Any plugin that supports only one of those browsers has no way of "politely refusing" to run in the other.

This is especially the case for complex plugins that use OS APIs that, for some reason, don't work in certain browsers, do work in others, and would also work in a downloaded resource launched by the default application.

In this case, on detecting that the browser was one that didn't support it, the plugin could do the downloading and launch the other application. To do this in a way that doesn't surprise or confuse the user, it would have to look like the browser was doing it. This is a simpler alternative, since the code already exists in the browser for:

• asking about downloads in the user's language
• placing them in a common well-known Downloads location
• allowing the user to track the download from the browser
• launching the default app (or not)
• allowing the user to delete the download from the browser

etc.

This proposal is to add a mechanism to allow plugins to politely "opt-out" when two existing NPAPI calls are made.

Specification

One new error value is added for return values for the following existing routine. That error value indicates that the plugin requests the browser to act like the plugin doesn't exist at that time.

Return Value:

• NPERR_PLUGIN_OPT_OUT (value to be determined): returning this value means the browser should act as if the mime type is unhandled and exhibit its default behavior in that case, as if the plugin wasn't installed.

Procedures:

• NP_Initialize: The plugin returns NPERR_PLUGIN_OPT_OUT when the it detects a permanent context (like architecture, or unsupported browser). It is expected that the browser should then always act as if the plugin didn't exist. The browser may remember this and never call the plugin again, or it may call NP_Initialize every time a resource with the appropriate mime type(s) is loaded. In that case the intention of this specification is that the plugin will return the same error code each time.

Compatibility

Since both these routines can return errors currently, there shouldn't be any check necessary to see if the browser handles this specific error in the right way. The plugin should expect that any browser that does not support this specific error will behave as they currently do on errors (which for the most part is showing either a blank area or a "plugin failure" message).

Objections

Snippets rom Stuart Morgan, causing Rudi to withdraw the proposal:

It sounds like what you are trying to do is simply not well suited to NPAPI; it sounds like important parts of your planned UX are based on things that browsers don't officially support and are in at least some cases actively discouraged. The idea of adding something to the NPAPI spec whose sole purpose sounds like it would be encouraging the creation of plugins that are based on unsupported approaches that only work in some browsers (probably by luck) concerns me quite a bit.

Except that when a user turns a plugin off, they know what's happening. Separately from the philosophical question of whether this belongs in the platform at all, the user experience seems like it would be pretty confusing: the user installs a plugin, opens a page with the relevant content, and sees... exactly what they saw before. Maybe they know about their browser's plugin-display UI, or maybe they post on a user support form and get pointed there by a more knowledgeable user, and when they go there they see an enabled plugin that handles the right type. Why is it being ignored? They have no idea.

From the browser side, this would almost certainly lead to a bunch of bug reports and user support requests because the obvious conclusion if two browsers see a plugin but one is ignoring it for no apparent reason is that there's a browser bug.