5 ms·
They needed to revamp the plugin architecture in order to support multithreading. The current FF extension API relies on the fact that the browser UI and the We
by pygy_ 10y ago
They needed to revamp the plugin architecture in order to support multithreading. The current FF extension API relies on the fact that the browser UI and the Web content share the same OS thread.
Google Chrome was built with multithreading in mind from the ground up (well, even multiple processes), and its extension API was designed around that architecture.
I think Mozilla made the right choice by picking and extending an existing API that has seen a lot of real world code written against it, rather than inventing a new, incompatible one.
- Animats 10y agoThey needed to revamp the plugin architecture in order to support multithreading. The current FF extension API relies on the fact that the browser UI and the Web content share the same OS thread. No, it doesn't. The long-obsolete XUL API did, but the current Jetpack API does not. There's a per-addon task and a per-page task, which communicate via message passing.
- pygy_ 10y agoOh my bad, I mixed things up...
- jupenur 10y agoJetpack/SDK still isn't fully E10s compatible, see https://developer.mozilla.org/en-US/Add-ons/SDK/Guides/Multiprocess_Firefox_and_the_SDK https://developer.mozilla.org/en-US/Add-ons/SDK/Guides/Multi...
- Animats 10y agoOnly if you use low-level APIs from the "privileged module" list.[1] The main high-level Jetpack APIs are multiprocess-compatible. [1] https://developer.mozilla.org/en-US/Add-ons/SDK/Low-Level_APIs https://developer.mozilla.org/en-US/Add-ons/SDK/Low-Level_AP...