=== It sounds like you're copying Google.... ===The Chrome extension API was designed to work well with process separation and we are certainly taking inspiration from it and copying functionality where it makes sense. In other areas it doesnHowever, there will be differences. We won'timplement all of Chrome's APIs, and we will implement our own APIs.=== How will Imagine the WebExtensions API be different from the Chrome Extension API===You could imagine APIs as a Venn Diagram of diagram. In the two extension middle are cross-browser APIsfor content scripts, tabs, and windows. One circle is Chrome's, In the other WebExtensionsFirefox side are APIs for toolbars and sidebars. The overlapping On the Chrome side are are basic extension functionality (APIs for Google''give some examples'')s cloud services.
Outside of that overlap area would === How will WebExtensions be cross-browser if you're extending Google's API? === Unlike the areas of differentiation. For exampleweb platform, we don't have much interest in providing easy access expect every browser to Google's services though implement every aspect of WebExtensionsin the same way. Hopefully there will be APIs that all browsers agree on, and they will work essentially the same way in all browsers. We do however want to support certain use cases But there will also be APIs that donare more browser-specific. For example, it't seem to be s unlikely that Chrome will ever support a toolbar API, but Firefox probably will. Even without perfect compatibility between browsers, a priority common API still has many advantages for Googleextension developers. If developers stay within the common API, their extensions will automatically work across browsers. We have identified a few such areas that we want Even if developers choose to support such as aduse browser-blockingspecific APIs, tab managementtheir extensions may be usable on other browsers through feature detection and fallbacks. For example, UI modification and time/location shifting contentan extension using a toolbar API might be able to fall back to the browser action API on other browsers.
=== Why WebExtensions and not Jetpack? ===
Finally, Jetpack doesn't solve the problem that add-on developers must code for two very different APIs. Basing WebExtensions off Chrome's API means that developers who stick to the common APIs will only have to maintain one codebase.
=== How will WebExtensions be cross-browser if you're extending Google's API? ===
Unlike the web platform, we don't expect every browser to implement every aspect of WebExtensions in the same way. Hopefully there will be APIs that all browsers agree on, and they will work essentially the same way in all browsers. But there will also be APIs that are more browser-specific. For example, it's unlikely that Chrome will ever support a toolbar API, but Firefox probably will.
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 will automatically work across browsers. Even if developers choose to use browser-specific APIs, their extensions may be usable on other browsers through feature detection and fallbacks. For example, an extension using a toolbar API might be able to fall back to the browser action API on other browsers.
=== Which add-ons will stop working after the deprecation? ===
