Confirm
945
edits
Changes
no edit summary
This FAQ, like WebExtensions, will be evolving over the coming weeks. Additional information will follow, and we'll update the [[WebExtensions ]] page as we post more detailed information.=== It sounds like you've made decisions without community input ===We're just getting started with WebExtensions, and have begun with a set of APIs that are commonly used with Chrome so people can kick the tires. We don't want to be a Chrome copy, and want to ensure we differentiate while integrating Electrolysis and other initatives into Firefox. 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.
=== It sounds like you're copying Google... ===
=== Why WebExtensions and not Jetpack? ===
There are several a number of reasons why we chose to start with Chrome's focus development on the WebExtension API. First, there are more extensions already written for other products that will support it , and more developers that will be familiar with developing for it. Second, it It has built-in support for content blocking, which Jetpack lacks. These content blocking APIs are used by a lot of many ad -blocking and anti-tracking extensions that are popular, which Jetpack lacks. Jetpack won't solve the problem that add-ons, which are some 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 most popularcommon APIs will be able to work off of a common codebase, and port extensions more simply between browsers.
In Jetpack's favor, it has a powerful module system similar to the one in node.js. However, given that JavaScript will soon have built-in support for modules, this won't be an advantage for long.
We don't want to limit what add-ons can do in Firefox. The process we've started is designed to understand how we can extend Firefox in ways that are less brittle than the current XUL/XPCOM system. We will work with every developer who is interested to make their add-on work in Firefox, and work to provide the functionality required in as many cases as possible. That said, there is a risk that some add-ons may be lost not transition if they are unmaintained not maintained or have maintainers who lack the time to port their add-on.
=== I'm writing a new extension today. What API should I use? ===
=== Won't this limit experimentation? ===
If WebExtensions were ultimately limited to the Chrome model, it would. But we're actually designing a system providing extension authors with the flexibility to implement innovative features that the WebExtension API doesn't currently allow. [https://discourse.mozilla-community.org/t/proposal-native-js-to-embrace-extend-the-webextensions-api/3457 Some discussion] has already begun. The intent is for add-on authors to experiment through this mechanism, with the knowledge that there are no guarantees of compatibility between Firefox releases, and use that to inform future additions to the stable WebExtension API.
=== Why deprecate XUL now? Firefox is still using it internally. ===
Otherwise, the only part of the XPI file format that WebExtensions uses is the filename suffix. We haven't decided yet whether to use .xpi or .zip.
=== Are malicious addons really a problem? ===
Yes. Please read [https://blog.mozilla.org/addons/2015/04/15/the-case-for-extension-signing/ "The Case for Extension Signing"].
