Hacker News Reader

Comment by superkuh | Hacker News Reader

The problem you described actually happened with Firefox and Firefox forks not too long ago. Mozilla kicked out all traditional Firefox add-ons from their repository to "replace" them (note: they didn't actually replace the vast majority) with chrome style webextensions. Firefox forks were forced to implement and run their own add-on hosting system and API, and navigate the complex legal waters of re-hosting the add-ons if they wished to continue having access. One notable example of this is the Pale Moon browser. But it all turned out all right. The PM add-on "store" works great and is reliable.

It's not beyond the capabilities of efforts like Vivaldi or Brave to do the same as the Pale Moon team.

View on HN

And how many add-ons are updated and maintained specifically for Pale Moon - especially compared to the number of add-ons for Firefox for which that is the case?

Because that is the danger for the Chromium forks too - that nobody will bother with their forked store.

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.

> 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.

As 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.

Note 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-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).

Which honestly makes sense. Komodo is one of my favourite editors, but Christ working with XUL is painful!

> get rid of XUL

XUL is still used by the browser itself.

I 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.

Reply on news.ycombinator.com