Electrolysis/plugins: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
Line 1: Line 1:
= Plugins and e10s meeting notes =
= Plugins and e10s =
 
{{bug|0669200}}: Support windowed plugin instances for multiple content processes
 
== mac update ==
 
Main bug that fixes things is bug {{bug|1092630}}. Second bug with some earlier work is {{bug|1044182}}.
 
Work is happening here:
 
https://github.com/bdaehlie/gecko-dev/tree/macplugins-e10s-5
 
Only remaining issues before landing are test failures:
 
* TEST-UNEXPECTED-FAIL | /tests/layout/generic/test/test_plugin_mouse_coords.html | p1 mouse move Y - got 18, expected 38
* TEST-UNEXPECTED-FAIL | /tests/layout/generic/test/test_plugin_mouse_coords.html | p2 mouse move Y - got 18, expected 38
* TEST-UNEXPECTED-FAIL | /tests/layout/generic/test/test_plugin_mouse_coords.html | p3 mouse move Y - got 11, expected 31
 
and
 
* TEST-UNEXPECTED-FAIL | /tests/dom/plugins/test/mochitest/test_cocoa_focus.html | Plugin should not have focus. - got true, expected false
* TEST-UNEXPECTED-FAIL | /tests/dom/plugins/test/mochitest/test_cocoa_focus.html | Focus event count should be 4 - got 3, expected 4
* TEST-UNEXPECTED-FAIL | /tests/dom/plugins/test/mochitest/test_cocoa_window_focus.html | Plugin does not know its initial top-level window activation state! - expected PASS
* TEST-UNEXPECTED-FAIL | /tests/dom/plugins/test/mochitest/test_cocoa_window_focus.html | uncaught exception - Error: Error calling method on NPObject! at http://mochi.test:8888/tests/dom/plugins/test/mochitest/cocoa_window_focus.html:68


== typical messaging deadlocks ==
== typical messaging deadlocks ==

Revision as of 15:20, 5 May 2015

Plugins and e10s

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
Retrieved from "https://wiki.allizom.org/index.php?title=Electrolysis/plugins&oldid=1072262"