Electrolysis/plugins: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
No edit summary
Line 1: Line 1:
= 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 ==
== typical messaging deadlocks ==


Line 70: Line 78:
* content's main thread isn't caught up in the attached message queues problem afaict.
* 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.
** 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

Revision as of 15:16, 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