Firefox turns to Chrome, refusing support for old add-ons

Yesterday, the Mozilla Foundation announced about the upcoming major changes in the work of the Firefox browser. Trying to keep up with current trends, the browser switches to a scheme of work where a separate process will correspond to each individual tab. Unfortunately, the introduction of this scheme means that the browser will have to abandon the support of add-ons that work using the current API.

The project Electrolysis , which just has to ensure the work of each tab with its process, appeared back in 2009. But since then, it has been extremely sluggishly developing, and constantly moved to the freezing stage. The main problem faced by developers is the inability to make friends with the project with the existing API for add-ons.
')
The current browser API is called XPCOM (cross-platform component object model), which allows you to write add-ons in various languages: C ++, JavaScript, Java, through the XPConnect abstraction layer. This system has helped the emergence of a huge number of add-ons to the browser, which played a significant role in their popularity.

XPCOM allows add-ons to interact with the browser at a rather intimate level, complementing and changing the behavior of all its components, from interface elements to page rendering. Unfortunately, this system also has a reverse side - it is very difficult to cross it with the idea of ​​Electrolysis and separate processes for each tab. According to the canons of this idea, all add-ons should work in separate processes from the main browser, and in this form their interaction with Firefox internals is extremely difficult.

In an attempt to cross these two entities, Mozilla introduced the CPOWs protocol (cross process object wrappers) to communicate between processes. But the system turned out to be slow, and besides, it does not handle all possible interaction scenarios. In this regard, it is also decided to abandon it.

Firefox promises to maintain support for add-ons that use the high-level API if they do not use XUL (markup language to create dynamic user interfaces based on XML). In general, XPCOM, XUL and CPOW will disappear from the browser in a year and a half.

As a result, Mozilla injects an API called WebExtensions based on JavaScript and HTML, which Chrome and Opera already use, and Microsoft adds a very similar thing to its Edge. So the positive side of this venture is that it will be very simple (theoretically) for developers to write add-ons that will work in all modern browsers.

And the bad news for developers is that it will be necessary to redo the current additions to work in the new system. This means, in particular, that all add-ons that are no longer supported by the developers (but are still working) will sink into oblivion. At the same time, the organization itself recognizes that not all existing add-ons can be reproduced using the new API, since it simply does not have all the features that are present in the current API.

In addition, taking care of the safety of users, Mozilla is gradually introducing mandatory certification of add-ons to the browser. Already starting with the 42nd version of the browser, which will appear in November, it will be impossible to install add-ons without a digital signature. Such a signature will receive only those additions that will be approved by the organization, and will be distributed through the addons.mozilla.org repository.