Confirmed users
945
edits
WebExtensions/FAQ: Difference between revisions
Jump to navigation
Jump to search
no edit summary
No edit summary |
No edit summary |
||
| Line 1: | Line 1: | ||
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. | 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... === | === It sounds like you're copying Google... === | ||
| Line 10: | Line 12: | ||
=== Why WebExtensions and not Jetpack? === | === Why WebExtensions and not Jetpack? === | ||
There are | There are a number of reasons we chose to focus development on the WebExtension API. First, there are more extensions for other products that will support it, and more developers that will be familiar with developing for it. It has built-in support for content blocking, which are used by many ad-blocking and anti-tracking extensions that are popular, which Jetpack lacks. 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. | ||
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. | 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. | ||
=== Which add-ons will stop working when XUL/XPCOM is deprecated? === | |||
=== Which add-ons will stop working | |||
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. That said, add-ons may | 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 not transition if they are 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? === | === I'm writing a new extension today. What API should I use? === | ||
| Line 28: | Line 28: | ||
=== Won't this limit experimentation? === | === 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. | 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. === | === Why deprecate XUL now? Firefox is still using it internally. === | ||
| Line 42: | Line 38: | ||
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. | 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? === | === 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"]. | Yes. Please read [https://blog.mozilla.org/addons/2015/04/15/the-case-for-extension-signing/ "The Case for Extension Signing"]. | ||