Electrolysis/plugins
Plugins and e10s meeting notes
bug 0669200: Support windowed plugin instances for multiple content processes
mac update
bug 1044182: Plugin focus is broken in e10s on Mac
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
- can't happen (bug 1093693)
chrome -> sync sendmessage -> plugin chrome -> sync sendmessage -> plugin -> sync ipc -> content ?|? sync ipc -> chrome
- happens while chrome is dispatching messages, no sync/rpc calls on the stack?
- content could be in a sync call to either when this happens
chrome -> sync ipc -> content -> sync ipc -> plugin | sync ipc -> chrome
- can't happen (bug 1093693)
chrome -> sync ipc -> content ?|? sync ipc -> plugin -> sync sendmessage -> chrome
- can't happen?
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
- needs a fix?
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
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