Changes

 We're just getting started with WebExtensions, believe that moving Firefox away from XUL and have begun with XPCOM is a long-term strategic necessity. We need to find a set of APIs way to do that are commonly used with Chrome . We have announced WebExtensions and the deprecation as early as possible so people that we can kick get feedback from the tirescommunity on how to make the transition. We don't want know that WebExtensions will need to be a Chrome copy, and want to ensure we differentiate while integrating Electrolysis and other initatives into Firefoximproved. To innovate will require input and assistance from the community, which we are actively seeking. The path for WebExtensions will evolve in the coming weeks, months, and years, and we want the developer community to be a big part of that evolution.

The Chrome extension API was designed to work well with process separation and we are taking inspiration from it and copying functionality where it makes sense. However, there will be differences, and the goal of WebExtensions is not to copy Chrome or allow Chrome extensions to run unmodified in Firefox, but to simplify cross-browser development by providing commonly-supported methods and interfaces. We won't implement all of Chrome's APIs, and Chrome is unlikely to implement some of the APIs we add. Imagine the APIs as a [https://en.wikipedia.org/wiki/Venn_diagram Venn diagram]. In the middle are cross-browser APIs for content scripts, tabs, and windows. In the Firefox side are APIs for toolbars and sidebars and other UI elements. On the Chrome side are APIs for Google's cloud services.

Unlike the web platform, we don't expect every browser to implement every aspect of WebExtensions in the same way. But, even without perfect compatibility between browsers, a common API still has many advantages for extension developers. If developers stay within the common API, their extensions should work with minimal (or no!) modifications across browsers. Even if developers choose to use browser-specific APIs, their extensions may be usable on other browsers through feature detection and fallbacks, or through using browser-specific APIs that provide similar functionality. As an example, an extension using a toolbar API might be able to fall back to a browser action API on other browsers.

There are a number of reasons we chose to focus development on the WebExtension API. First, there are more Chrome extensions for other products that will support it, than Jetpack add-ons and more developers that who will be familiar with developing for itWebExtensions. It WebExtensions has built-in support for content blocking, which are is used by many ad-blocking and anti-tracking extensions that are popular, which ; Jetpack lackssuch APIs. Jetpack won't solve the problem that add-on developers must maintain a different codebase for each browser. Basing our initial implementation of WebExtensions off of Chrome's API means that developers who stick to the common APIs will be able to work off of a common codebase, and port extensions more simply between browsers.