Confirmed users
699
edits
Electrolysis/Short-Term Goals: Difference between revisions
Jump to navigation
Jump to search
→Implement core handling of plugins on one platform
(new goals) |
|||
| Line 95: | Line 95: | ||
== Implement core handling of plugins on one platform == | == Implement core handling of plugins on one platform == | ||
Multiple content processes that create instances of the same plugin (e.g. Flash) all need to talk to the same plugin subprocess. This requires refactoring our plugin architecture into two parts: (i) a "plugin subprocess" abstraction, which will continue to be managed by the chrome process, and a (ii) "plugin instance creator" piece, which will create and manage plugin instances of a given plugin type, on behalf of possibly many clients (content processes). Currently both are implemented by PPluginModule. When content processes are disabled, the implementation will look almost exactly like the current one. At the end of this milestone, the architectural foundations will be laid, and '''windowless''' plugins will work with multiple content process on at least one platform. | |||
Goal Date: TBD | There are two potentially large compatibility implications | ||
# With out-of-process content, the process of instantiating a plugin will change, and might require spinning the event loop to maintain a synchronous illusion. If we do end up needing to spin the event loop, there are potential web compat issues. | |||
# With out-of-process content, the chrome process will '''not''' be able to instantiate plugins. This obviously won't affect the Firefox frontend, but it will affect extensions. This isn't arbitrary or negotiable; it's just something that's not technically feasible to support without a heroic engineering effort (and since it's bad UX anyway, not at all worth that cost). We need to start communicating this to extension developers ASAP. | |||
This work will primarily happen in {{bug|641685}}. | |||
Owner: cjones Goal Date: TBD | |||
= Completed Goals = | = Completed Goals = | ||