Confirmed users
1,982
edits
Electrolysis/plugins: Difference between revisions
Jump to navigation
Jump to search
→attached input queues
| Line 91: | Line 91: | ||
== 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 | ||
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 bugs == | == follow up bugs == | ||