The plan towards offering Adblock Plus for Firefox as a Web Extension · 2017-04-12 08:23 by Wladimir Palant

TL;DR: Sometime in autumn this year the current Adblock Plus for Firefox extension is going to be replaced by another, which is more similar to Adblock Plus for Chrome. Brace for impact!

What are Web Extensions?

At some point, Web Extensions are supposed to become a new standard for creating browser extensions. The goal is writing extensions in such a way that they could run on any browser without any or only with minimal modifications. Mozilla and Microsoft are pursuing standardization of Web Extensions based on Google Chrome APIs. And Google? Well, they aren’t interested. Why should they be, if they already established themselves as an extension market leader and made everybody copy their approach.

It isn’t obvious at this point how Web Extensions will develop. The lack of interest from Google isn’t the only issue here; so far the implementation of Web Extensions in Mozilla Firefox and Microsoft Edge shows very significant differences as well. It is worth noting that Web Extensions are necessarily less powerful than the classic Firefox extensions, even though many shortcomings can probably be addressed. Also, my personal view is that the differences between browsers are either going to result in more or less subtle incompatibilities or in an API which is limited by the lowest common denominator of all browsers and not good enough for anybody.

So why offer Adblock Plus as a Web Extension?

Because we have no other choice. Mozilla’s current plan is that Firefox 57 (scheduled for release on November 14, 2017) will no longer load classic extensions, and only Web Extensions are allowed to continue working. So we have to replace the current Adblock Plus by a Web Extension by then or ideally even by the time Firefox 57 is published as a beta version. Otherwise Adblock Plus will simply stop working for the majority of our users.

Mind you, there is no question why Mozilla is striving to stop supporting classic extensions. Due to their deep integration in the browser, classic extensions are more likely to break browser functionality or to cause performance issues. They’ve also been delaying important Firefox improvements due to compatibility concerns. This doesn’t change the fact that this transition is very painful for extension developers, and many existing extensions won’t take this hurdle. Furthermore, it would have been better if the designated successor of the classic extension platform were more mature by the time everybody is forced to rewrite their code.

What’s the plan?

Originally, we hoped to port Adblock Plus for Firefox properly. While using Adblock Plus for Chrome as a starting point would require far less effort, this extension also has much less functionality compared to Adblock Plus for Firefox. Also, when developing for Chrome we had to make many questionable compromises that we hoped to avoid with Firefox.

Unfortunately, this plan didn’t work out. Adblock Plus for Firefox is a large codebase and rewriting it all at once without introducing lots of bugs is unrealistic. The proposed solution for a gradual migration doesn’t work for us, however, due to its asynchronous communication protocols. So we are using this approach to start data migration now, but otherwise we have to cut our losses.

Instead, we are using Adblock Plus for Chrome as a starting point, and improving it to address the functionality gap as much as possible before we release this version for all our Firefox users. For the UI this means:

Filter Preferences: We are working on a more usable and powerful settings page than what is currently being offered by Adblock Plus for Chrome. This is going to be our development focus, but it is still unclear whether advanced features such as listing filters of subscriptions or groups for custom filters will be ready by the deadline.

Blockable Items: Adblock Plus for Chrome offers comparable functionality, integrated in the browser’s Developer Tools. Firefox currently doesn’t support Developer Tools integration (bug 1211859), but there is still hope for this API to be added by Firefox 57.

to be added by Firefox 57. Issue Reporter: We have plans for reimplementing this important functionality. Given all the other required changes, this one has lower priority, however, and likely won’t happen before the initial release.

If you are really adventurous you can install a current development build here. There is still much work ahead however.

What about applications other than Firefox Desktop?

The deadline only affects Firefox Desktop for now; in other applications classic extensions will still work. However, it currently looks like by Firefox 57 the Web Extensions support in Firefox Mobile will be sufficient to release a Web Extension there at the same time. If not, we still have the option to stick with our classic extension on Android. Update (2017-05-18): Mozilla announced that Firefox Mobile will drop support for classic extensions at the same time as Firefox Desktop. So the option to keep our classic extension there doesn’t exist, we’ll have to make with whatever Web Extensions APIs are available.

As to SeaMonkey and Thunderbird, things aren’t looking well there. It’s doubtful that these will have noteworthy Web Extensions support by November. In fact, it’s not even clear whether they plan to support Web Extensions at all. And unlike with Firefox Mobile, we cannot publish a different build for them (Addons.Mozilla.Org only allows different builds per operating system, not per application). So our users on SeaMonkey and Thunderbird will be stuck with an outdated Adblock Plus version.

What about extensions like Element Hiding Helper, Customizations and similar?

Sadly, we don’t have the resources to rewrite these extensions. We just released Element Hiding Helper 1.4, and it will most likely remain as the last Element Hiding Helper release. There are plans to integrate some comparable functionality into Adblock Plus, but it’s not clear at this point when and how it will happen.

Commenting is closed for this article.