NPAPI:PluginOptOut - Revision history

Rudisherry: /* Status */

2012-03-23T15:32:32Z

Status

← Older revision		Revision as of 15:32, 23 March 2012
Line 1:		Line 1:
	= Status =		= Status =

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

	= Contributors =		= Contributors =

Rudisherry: Summarizing the objecctions that lead to withdrawing the proposal.

2012-03-23T15:16:36Z

Summarizing the objecctions that lead to withdrawing the proposal.

← Older revision		Revision as of 15:16, 23 March 2012
Line 44:		Line 44:

	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).		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.

Rudisherry: /* Contributors */

2012-03-23T15:13:24Z

Contributors

← Older revision		Revision as of 15:13, 23 March 2012
Line 5:		Line 5:
	= Contributors =		= Contributors =

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

Rudisherry: /* Status */

2012-03-23T15:13:09Z

Status

← Older revision		Revision as of 15:13, 23 March 2012
Line 1:		Line 1:
	= Status =		= Status =

	~~Under Consideration~~		No long under consideration (3/23/2012)

	= Contributors =		= Contributors =

Rudisherry: /* Contributors */

2012-03-21T21:35:42Z

Contributors

← Older revision		Revision as of 21:35, 21 March 2012
Line 5:		Line 5:
	= Contributors =		= Contributors =

	* Last modified: March 14, 2012		* Last modified: March 21, 2012
	* Authors: Rudi Sherry (Adobe Systems)		* Authors: Rudi Sherry (Adobe Systems)
	* Contributors:		* Contributors:

	= Overview =		= Overview =

Rudisherry: /* Specification */

2012-03-21T21:16:17Z

Specification

← Older revision		Revision as of 21:16, 21 March 2012
Line 31:		Line 31:
	= Specification =		= Specification =

	One new error value is added for return values for the following existing ~~routines~~. That error value indicates that the plugin requests the browser to act like the plugin doesn't exist at that time.		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:		Return Value:

	* <code>NPERR_PLUGIN_OPT_OUT</code> (value to be determined): returning this value ~~from one of the three calls~~ means the browser should act as if the mime type is unhandled and exhibit its default behavior in that case.		* <code>NPERR_PLUGIN_OPT_OUT</code> (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:		Procedures:

	* <code>NP_Initialize</code>: The plugin returns <code>~~NPERR_PLUGIN_REFUSED~~</code> 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 <code>NP_Initialize</code> 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.		* <code>NP_Initialize</code>: The plugin returns <code>NPERR_PLUGIN_OPT_OUT</code> 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 <code>NP_Initialize</code> 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.
	** Q: Should the plugin expect <code>NP_Shutdown</code> called after that?
	* <code>NPP_NewStream</code>: This is returned when the plugin can handle some resources but perhapse not others. There may be certain internal settings in the plugin that allow or disallow some resources, but that cannot be communicated with the browser. The browser would then act as if the plugin didn't exist for that one stream.
	** Q: would this make sense on 'refresh' for a stream the plugin already accepted?

	= Compatibility =		= 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).		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).

Rudisherry: /* Overview */

2012-03-21T20:27:17Z

Overview

← Older revision		Revision as of 20:27, 21 March 2012
Line 16:		Line 16:

	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.		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.		This proposal is to add a mechanism to allow plugins to politely "opt-out" when two existing NPAPI calls are made.

Rudisherry: Created page with "= Status = Under Consideration = Contributors = * Last modified: March 14, 2012 * Authors: Rudi Sherry (Adobe Systems) * Contributors: = Overview = Currently there are no m..."

2012-03-14T19:34:31Z

Created page with "= Status = Under Consideration = Contributors = * Last modified: March 14, 2012 * Authors: Rudi Sherry (Adobe Systems) * Contributors: = Overview = Currently there are no m..."

New page

= Status =

Under Consideration

= Contributors =

* Last modified: March 14, 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 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 routines. That error value indicates that the plugin requests the browser to act like the plugin doesn't exist at that time.

Return Value:

* <code>NPERR_PLUGIN_OPT_OUT</code> (value to be determined): returning this value from one of the three calls means the browser should act as if the mime type is unhandled and exhibit its default behavior in that case.

Procedures:

* <code>NP_Initialize</code>: The plugin returns <code>NPERR_PLUGIN_REFUSED</code> 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 <code>NP_Initialize</code> 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.
** Q: Should the plugin expect <code>NP_Shutdown</code> called after that?
* <code>NPP_NewStream</code>: This is returned when the plugin can handle some resources but perhapse not others. There may be certain internal settings in the plugin that allow or disallow some resources, but that cannot be communicated with the browser. The browser would then act as if the plugin didn't exist for that one stream.
** Q: would this make sense on 'refresh' for a stream the plugin already accepted?

= 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).