Electrolysis/plugins
From MozillaWiki
Contents
Plugins and e10s
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
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
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
