WebExtensions are making some people happy, some people angry, many people ask questions.
Some of the answers can be found here, more to come as add-on developers keep discussing this hot topic.
My favourite one: No, your add-ons' ability and your own creativity won't be limited by the new API.

3 Responses to “WebExtensions FAQ”

  1. #1 Ian Thomas says:

    What's with the framebuster on a blog? I use newsblur as a feed reader, but clicking on your post rudely kicked me out of newsblur so your site could have a little extra space.

  2. #2 J. McNair says:

    Cynical Translation into plain(er) English:

    It sounds like you've made decisions without community input, why?
    Mozilla leadership did make this decision with little community input, and appear to be feeling the sting of it. They wanted to get something ready now, and have quietly committed engineers to working on compatibility with Chrome's API. Now that everyone's paying attention, they'll add the missing bits as dictated by developer demand.

    Why are these big changes needed?
    XPCOM is extremely difficult to support as a public-facing extension API. XUL and XBL are technical baggage.

    It sounds like you're copying Google...
    Mozilla is copying and FORKING the Chrome extension API, because it is popular, documented, and easy for simple extensions. The Chrome extension API was designed to work well with sandboxes and process separation, but Mozilla may add and change what developers need.

    How will WebExtensions be cross-browser if you're extending Google's API?
    Except for a small, shared API subset, WebExtensions won't be cross-browser. Basing the NEW API on what Chrome uses might attract Chrome extension developers to our platform. Microsoft is doing something similar for Edge.

    Why WebExtensions and not Jetpack?
    JetPack is incomplete and needs significant work to work well with future Firefox changes. Mozilla already has engineers implementing Chrome extension API compatibility, and decided that the potential benefits of WebExtensions outweigh the potential benefits of fixing JetPack. The community hope is that Mozilla will commit engineering resources to insure that WebExtensions will make JetPack redundant.

    Which add-ons will stop working when XUL/XPCOM is deprecated?
    All of the ones still using XUL/XPCOM will stop working, unless they are rewritten. Note that final deprecation may not be until 2018.

    I'm writing a new extension today. What API should I use?
    Unless you're writing a simple Chrome extension, wait and see!

    Won't this limit experimentation?
    For right now, yes. Eventually, Mozilla's NEW new extension API may be rich enough that this won't be a worry.

    Why deprecate XUL now? Firefox is still using it internally.
    Gecko is moving away from it, and all extensions and downstream projects (like Thunderbird and SeaMonkey) will be forced to migrate. [insert future of Firefox blog post]

    Why keep the .xpi packaging format?
    There's no compelling reason to change it, oddly enough.

    Are malicious addons really a problem?

    Yes. Please read "The Case for Extension Signing".

  3. #3 LOL says:

    Firefox kicks itself out of the market. Fullstop. In the last months Mozilla made choices against a huge userbase slapping them in the face. So it's ok if it dies, it's well deserved. Some kind of fork or underdog will take its place and Mozilla can go and cry a river with their cheap Chrome rippoff

Bad Behavior has blocked 927 access attempts in the last 7 days.