Electrolysis/plugins

Plugins and e10s

Preferences related to plugins and process timeouts

Platform Prefs

Preference	Default	Description
dom.ipc.plugins.timeoutSecs	45	How long a chrome to plugin synchronous IPC message is allowed to process before we consider it "hung".
dom.ipc.plugins.contentTimeoutSecs	10	How long a content to plugin synchronous IPC message is allowed to process before we notify the chrome process of a plugin hang.
dom.ipc.plugins.processLaunchTimeoutSecs	45	How long a plugin launch is allowed to take before we consider it failed.
dom.ipc.plugins.parentTimeoutSecs	-1	How long a plugin process will wait for a response from the parent to a synchronous request before terminating itself. After this point the child assumes the parent is hung. Currently disabled.

Windows specific

Preference	Default	Description
dom.ipc.plugins.hangUITimeoutSecs	11	How long a chrome to plugin synchronous IPC message is allowed to process before we display the plugin hang dialog.
dom.ipc.plugins.hangUIMinDisplaySecs	10	Minimum time that the plugin hang UI will be displayed.
dom.ipc.plugins.flash.disable-protected-mode	false	We set this if we detect multiple chrome hangs during a session. We do not set it back. Active in both non-e10s and e10s.

Firefox Specific

Preference	Default	Description
dom.ipc.reportProcessHangs	false in debug builds, true otherwise	Enable or disable the ipc ProcessHangMonitor.

No timeouts are set for DEBUG builds, see all.js and firefox.js.

typical messaging deadlocks

case #1:

chrome -> sync ipc -> plugin -------+
                                    |
chrome <- sync sendmessage <--------+

case #2:

chrome -> sync sendmessage -> plugin -+
                                      |
chrome <- sync ipc <------------------+

case #3:

chrome -> sync ipc -> plugin -> plugin never responds back

non-e10s mitigation

case #1:

chrome -> sync ipc -> plugin ---------------------+
                                                  |
chrome | windowsmessageloop <- sync sendmessage <-+

case #2:

• various tricks, I believe windowsmessageloop is also active in the child

case #3:

• plugin hang dialog

e10s mitigation

chrome | sync ipc -> plugin
chrome -> sync ipc -> content -> sync ipc -> plugin | sync ipc -> chrome

• bug 1093693

chrome -> sync sendmessage -> plugin -> sync ipc -> content -> sync ipc -> chrome

• happens while chrome is dispatching messages, or in a sync/rpc ipc call.
• we have assertion mechanisms to warn about this in non-e10s.
• bug 1098057

chrome -> sync ipc -> content -> sync ipc -> plugin -> sync sendmessage -> chrome

• bug 1098055

content -> sync ipc -> plugin -> plugin never responds back

• slow plugin scripts cause this pretty often
• with e10s, what would we get?
  • content hang
  • tab rendering spinners
  • there's no hang dialog
  • we have bugs on dealing with content hangs which overlap this
  • bug 1096664

plugin deadlock

since the plugin's main thread is bound to chrome's main thread, if either slows down, or hangs, they both slow down or hang.

non-e10s mitigation

none

e10s mitigation

none

e10s notes:

• the content process runs freely initially when chrome or plugin hang, until it sends a sync message to either.
• content's main thread isn't caught up in the attached message queues problem afaict.
  • media related code might break this if native ui is parented to chrome, need to investigate.

attached input queues

bug 0818059: Detach the plugin-container input queue from the browser input queue

1) focus / flicker problems caused by conflicting foreground status between the browser window and the plugin window

• I’m not sure if this is something we can mitigate in code, some heavy debugging of focus events down in widget might shed some light on this.

2) random hangs in modal loops associated with window actions like dragging or resize

• I’m seeing random lockups when manipulating windows or when the plugin window gets clipped by other desktop windows.
• Unfortunately attaching a utility like procdump prevents me from reproducing to get stacks.
• It appears the desktop switches to a synchronous event model for drag/resize loops. This means the desktop gets caught up in these lockups.
• Exiting these lockups requires switching desktop focus using alt-tab. Everything frees up after that.

3) Plugin focus is broken for secondary windows like fullscreen

• we can hand ‘foreground taking rights’ off to flash if we can find the right process handle, but we can’t revoke it.

Moving window management down to the compositor will work on linux, but I don't see the point if we don't have a Windows solution. The three issues above need to be solved before we consider this on Windows, until then we really have no choice but to manage native plugin widgets on the main thread.

Follow up:

• bug 1095754: Sync remote plugin widget clipping, bounds, and visibility with the render frame
• file a support request fishing for help?

follow up bugs

• bug 1093693: Plugin hangs with new plugin IPC code
• bug 1095754: Sync remote plugin widget clipping, bounds, and visibility with the render frame
• bug 1095761: Fixup Windows focus routing in the PluginInstances for e10s
• bug 1095776: Deal with spurious WM_PAINT messages on plugin parent windows
• bug 1098055: Sync SendMessage calls from plugin may deadlock in the new plugin model
• bug 1098057: Sync SendMessage calls from chrome may deadlock in the new plugin model
• bug 1096664: Plugin hang detector is currently disabled with e10s
• bug 1096080: ProcessFirstMinidump processing appears broken