Electrolysis/plugins: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
|||
Line 46: | Line 46: | ||
chrome -> sync ipc | plugin | chrome -> sync ipc | plugin | ||
* | * can't happen | ||
chrome -> sync sendmessage -> plugin | chrome -> sync sendmessage -> plugin | ||
Line 53: | Line 53: | ||
chrome -> sync ipc -> content -> sync ipc -> plugin -> sync ipc | chrome | chrome -> sync ipc -> content -> sync ipc -> plugin -> sync ipc | chrome | ||
* | * can't happen | ||
chrome -> sync ipc -> content | chrome -> sync ipc -> content | sync ipc -> plugin -> sync sendmessage -> chrome | ||
* can happen? | * can't happen? | ||
content -> sync ipc -> plugin -> plugin never responds back but keep pumping messages | content -> sync ipc -> plugin -> plugin never responds back but keep pumping messages |
Revision as of 15:27, 9 November 2014
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 but keep pumping messages
non-e10s mitigation
case #1:
chrome -> sync ipc -> plugin ---------------------+ | chrome | windowsmessageloop <- sync sendmessage <-+
case #2:
- various tricks
case #3:
- plugin hang dialog
e10s mitigation
chrome -> sync ipc | plugin
- can't happen
chrome -> sync sendmessage -> plugin
- 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
chrome -> sync ipc -> content | sync ipc -> plugin -> sync sendmessage -> chrome
- can't happen?
content -> sync ipc -> plugin -> plugin never responds back but keep pumping messages
- content hang?
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
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