Plugins:DisablePluginHangMonitor

From MozillaWiki
Jump to: navigation, search

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 NPN_SetValue()

I am proposing a new value that can be passed to NPN_SetValue():

   NPPVpluginPushDisableHangMonitorBool

This value would be recognized by NPN_SetValue(), but not by NPN_GetValue().

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

  • When the plugin passes true, it is telling the browser, "Push the state of your plugin hang monitor, and then disable the plugin hang monitor."
  • When the plugin passes false, 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 NPPVpluginPushDisableHangMonitorBool. 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 NPN_SetValue() is that if it does not recognize the variable that was passed in, it returns an error code such as NPERR_INVALID_PARAM, 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 NPPVpluginPushDisableHangMonitorBool 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 NPERR_NO_ERROR. 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 true, 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 false, 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 NPPVpluginPushDisableHangMonitorBool 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.