View source for Plugins:DisablePluginHangMonitor

= Status =

Under consideration.

= Background =

Recently, browsers are moving in the direction of warning the user when a plugin appears to be hung.  In Google Chrome, for example, after a plugin has been hung for 30 seconds, the browser displays this message:

   The following plug-in is unresponsive: Shockwave Flash
   Would you like to stop it?

Considering that more and more browsers are moving to a model of running plugins out-of-process, it would not be surprising if other browsers begin having similar messages.

While this is a useful feature, there are certain special circumstances under which a plugin must deliberately hang.  The most common case (in fact, the only case I know of) is when the plugin supports the concept of debugging.  For example, Adobe's Flash Player can attach to a debugger, and so can Google's GWT.

When the plugin is at a breakpoint, it typically needs to completely block.  In that kind of scenario, it is undesirable to have the above warning message appear.

This proposal offers a small extension to the plugin API that allows a plugin to tell the parent browser to temporarily stop detecting when the plugin is hung.

= Current Proposal =

* Last modified: September 25, 2009
* Author: Mike Morearty (Adobe)
* Contributors:

== New value for <code>NPN_SetValue()</code> ==

I am proposing a new value that can be passed to <code>NPN_SetValue()</code>:

    NPPVpluginPushDisableHangMonitorBool

This value would be recognized by <code>NPN_SetValue()</code>, but not by <code>NPN_GetValue()</code>.

The browser would expect a value of <code>true</code> or <code>false</code> to be associated with this value:

* When the plugin passes <code>true</code>, it is telling the browser, "Push the state of your plugin hang monitor, and then disable the plugin hang monitor."
* When the plugin passes <code>false</code>, it is telling the browser, "Pop the previous state of the plugin hang monitor."

=== Example ===

Here is an example of how a plugin would typically use <code>NPPVpluginPushDisableHangMonitorBool</code>.  Let's say the plugin has connected over a socket to a plugin-specific debugger, and has hit a breakpoint.  It is blocked, waiting for the user to issue some sort of "resume" command.  The plugin's code might look like this:

  NPN_SetValue(instance, NPPVpluginPushDisableHangMonitorBool, (void*)true);
  processSocketMessages();
  NPN_SetValue(instance, NPPVpluginPushDisableHangMonitorBool, (void*)false);

== Backward compatibility ==

The behavior of <code>NPN_SetValue()</code> is that if it does not recognize the variable that was passed in, it returns an error code such as <code>NPERR_INVALID_PARAM</code>, but it does not otherwise interfere with the operation of the plugin.  So, a plugin would be free to pass this value to an older browser, and be confident that if the older browser did not recognize this parameter, the result would be essentially a no-op.

== Browser-specific behavior ==

Not all browsers have any sort of plugin hang monitor, and of those that do, there may be variations in their behavior.  There are a few ways in which the behavior of <code>NPPVpluginPushDisableHangMonitorBool</code> may vary slightly from one browser to the next:

* As described above, if an older browser does not recognize this variable, it would return an error code.
* A newer browser might recognize this variable, but might not have a hang monitor.  In that case, the browser would ideally return <code>NPERR_NO_ERROR</code>.  However, it is common practice for plugins to return error codes for any variable that they don't explicitly handle.  Therefore, plugin authors would be wise to code defensively, and not assume a particular return value.
* When a plugin passes <code>true</code>, it is really only requesting that the plugin monitor be disabled for ''that one instance'' of ''that one plugin.''  However, due to implementation issues, it may be difficult for some browsers to have such fine-grained control over their plugin hang monitor, so a browser is free to respond more broadly, such as by disabling its plugin monitor for all instances of that plugin, or disabling its plugin monitor for all plugins in that web page, or disabling its plugin monitor entirely.
* When the plugin passes <code>false</code>, browsers may differ in how they restore their plugin hang monitor.  For example, suppose a browser's hang monitor normally waits 30 seconds before displaying its warning.  Some browsers may implement <code>NPPVpluginPushDisableHangMonitorBool</code> by pausing their timer -- for example, if the plugin has already been hung for ten seconds, and then the plugin calls push and then pop, the browser might leave 20 seconds on its timer.  Other browsers may reset their timer -- in the above example, they may put the timer back at 30 seconds remaining before a hang is detected.