Electrolysis/plugins: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
No edit summary |
||
| Line 1: | Line 1: | ||
= Plugins and e10s meeting notes = | = Plugins and e10s meeting notes = | ||
{bug|0669200}: Support windowed plugin instances for multiple content processes | {{bug|0669200}}: Support windowed plugin instances for multiple content processes | ||
== mac update == | == mac update == | ||
| Line 81: | Line 81: | ||
== attached input queues == | == attached input queues == | ||
{bug|0818059}: Detach the plugin-container input queue from the browser input queue | {{bug|0818059}}: Detach the plugin-container input queue from the browser input queue | ||
== follow up bugs == | == follow up bugs == | ||
{bug|1093693}: Plugin hangs with new plugin IPC code | * {{bug|1093693}}: Plugin hangs with new plugin IPC code | ||
{bug|1095754}: Sync remote plugin widget clipping, bounds, and visibility with the render frame | * {{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|1095761}}: Fixup Windows focus routing in the PluginInstances for e10s | ||
{bug|1095776}: Deal with spurious WM_PAINT messages on plugin parent windows | * {{bug|1095776}}: Deal with spurious WM_PAINT messages on plugin parent windows | ||
Revision as of 15:19, 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
- never happens
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
- never happens
chrome -> sync ipc -> content -> sync ipc -> plugin -> sync sendmessage -> chrome
- can 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