Last year we ported our Chrome extension to Edge, so when Firefox announced its plans, we had a good idea of what we wanted to do and how to go about it. How was the experience of finding WebExtensions APIs to replace legacy APIs? What are some advantages and limitations? Walk us through the process of how you are making the transition. The benefit, from our standpoint, was that by using this API our software would be on a similar codebase and have similar features and functionalities to what we do on some of the other browsers we support. With the Firefox SDK set to be deprecated, we knew our extension would slowly become unusable, so it made sense to transition to the WebExtension API. Why did you decide to transition your add-on to WebExtensions APIs? Since the APIs were a little different, we ended up having to modify some modules to use the Firefox Add-on SDK. The Firefox Add-On SDK was being promoted at the time, which wasn’t compatible with the Chrome Extension API, so we went through the Chrome code to identify areas where we could leverage work we had done previously. What add-on technologies or APIs were used to build your add-on? It seemed like a natural place for us to be. We had seen some early success on Chrome and Safari and believed we could replicate that success on Firefox, which had developed a good community of users that downloaded add-ons for Firefox. We created our original Firefox extension in 2014. What does it do, when was it created, and why was it created?

Please provide a short background on your add-on. You can also contact us via these methods. You can read more about the AdBlock extension here.įor more resources on updating your extension, please check out MDN. They have finished transitioning to WebExtensions, by way of porting their data using Embedded WebExtensions. AdBlock for Firefox is a fast and powerful ad blocker with over 40 million users.

Mozilla firefox extensions adblock