5 ms·
Ironically Firefox killed their extension API to be compatible with Chrome's extensions. Now they probably don't want to be compatible with the new Chrome API.
by guelo 7y ago
Ironically Firefox killed their extension API to be compatible with Chrome's extensions. Now they probably don't want to be compatible with the new Chrome API.
- AsyncAwait 7y ago> Ironically Firefox killed their extension API to be compatible with Chrome's extensions. This is misleading. They deprecated the old API primarily to be able to do multi-process and get rid of XUL.
- kibwen 7y agoAs well as to expose a stable extension API (no more XUL extensions breaking randomly on every browser update) and to enforce any sort of security boundary/permissions system.
- metildaa 7y agoNote that this was done after two prior failed attempts to rewrite the CSS engine for multithread in C++: https://hacks.mozilla.org/2019/02/rewriting-a-browser-component-in-rust/ https://hacks.mozilla.org/2019/02/rewriting-a-browser-compon... Its sad to lose DownThemAll and the plethora of othwr XUL extensions, but having performant multicore support is critical given the shift to having many cores (as single thread performance improvements become uncommon).
- girvo 7y agoWhich honestly makes sense. Komodo is one of my favourite editors, but Christ working with XUL is painful!
- qbaqbaqba 7y ago> get rid of XUL XUL is still used by the browser itself.
- dmitryminkovsky 7y agoI recently used the webRequest API in Firefox and it is already more robust than the Chrome equivalent. For example, you can write stream filters to process request responses. No so in Chrome, where you have no such capability.