WebExtensions in Firefox 51

Firefox 51 landed in Developer Edition this week, so we have another update on WebExtensions for you. In this update, we’re making it easier for you to port your existing add-ons to WebExtensions. In addition to being fully compatible with multiprocess Firefox, WebExtensions are becoming the standard for add-on development.

Embedded WebExtensions

In Firefox Developer Edition, you can now embed a WebExtensions add-on inside an existing SDK or bootstrapped add-on.

This is especially useful to developers of SDK or bootstrapped add-ons who want to start migrating to WebExtensions and take advantage of new APIs like Native Messaging, but can’t fully migrate yet. It’s also useful for developers who want to complete data migration towards WebExtensions, and who want to take parts of their add-on that are not compatible with multiprocess Firefox and make them compatible.

For more documentation on this, please head over to MDN or check out some examples.

If you need help porting to WebExtensions, please start with the compatibility checker, and check out these resources.

Manifest Change

Because of confusion around the use of strict_min_version in WebExtensions manifests, we’ve prevented the use of * in strict_min_version, for example 48.* is no longer valid. If you upload an add-on to addons.mozilla.org we’ll warn you of that fact.

API Changes

The clipboardWrite permission is now enabled which removes the need to be in a user gesture. This is usable from extension tabs, popups and content scripts.

When a WebExtensions add-on is uninstalled, any local storage is now cleared. If you’d like to persist data across an uninstall then you can use the upcoming sync storage.

The management API now supports the uninstallSelf and getSelf methods. The idle.queryState API has been updated to accurately reflect the state, previously it always returned the value “idle”.

In the webRequest API, onBeforeRequest is now supported in Firefox Nightly and Developer Edition. There are some platform changes that are required to get that to land in a Release version of Firefox.

Developers have been testing out Native messaging and a couple of bugs were filed and fixed on that. New, more detailed, documentation has been written. One of the useful pieces of feedback involved the performance of the round-trip time, and that has now improved.

There has been a few improvements to the appearance of popup windows including the popup arrow, the corners of the popup and reducing flicker on the animation. Here’s a before and after:

popup-before

popup-after

Out of process extensions

Now that the majority of the work multi process Firefox has been completed, we are looking ahead to the many improvements it can bring. One of them is allowing WebExtensions to be run in a separate process. This process-sandboxing of add-ons will bring clear performance and security benefits.

But before we can do that, there is quite a bit of work that needs to be done. The main tracking bug lists some of these tasks. There is also a video of Rob Wu presenting the work he has done on this. There currently isn’t a timeline for when this will be landed, but the work is progressing.

Recognition

We’d also like to give a thank you to four new contributors to WebExtensions, who’ve helped with this release. Thanks to sj, Jorg K, fiveNinePlusR and Tomislav.

Update: link to Robs presentation fixed.

11 responses

  1. Bug Report: Broken Link: “video of Rob Wu” links to same place as “main tracking bug” wrote on :

    Ugh: I just posted a bug report & it tells me “No responses yet”…I understand if it went to moderation, but PLEASE TELL ME THAT. Let me SEE if my post went thru, even to moderation.

    1. Andy McKay wrote on :

      Thanks, presentation link fixed.

    2. Gerd Neumann wrote on :

      > Ugh: I just posted a bug report & it tells me “No responses yet”…I understand if it went to moderation, but PLEASE TELL ME THAT. Let me SEE if my post went thru, even to moderation.

      This is a problem I have with all the mozilla blogs. Also, it the comment box does not say which html tags are filtered and which not. Very annoying when discussing about technology, e.g. see this comment at https://hacks.mozilla.org/2016/08/a-few-html-tips/#comment-20154 (“Hi, could you clarify? I fear that the comment filter might have stripped some characters.”)

      Please fix your WordPress settings. I very much appreciate that you do these blog posts in order to reach out to users and developers. Fixing these takes about half an hour.

      What’s the place I can report a bug with the blog itself?

      1. Andy McKay wrote on :

        In Bugzilla here: https://bugzilla.mozilla.org/enter_bug.cgi?product=Websites&component=blog.mozilla.org

  2. Paul Morris wrote on :

    So, the MDN page for embedded WebExtensions[1] says that “JPM 1.2.0 (currently unreleased)” is required for SDK add-ons. Any timeline for when that will be released? I couldn’t find a bug for it on bugzilla.

    [1] https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Embedded_WebExtensions

    1. Andy McKay wrote on :

      Thanks for the reminder, 1.2 was just released: https://github.com/mozilla-jetpack/jpm/tags

      1. Paul Morris wrote on :

        That’s great, thanks!

  3. James Dean wrote on :

    Hi,

    I noticed your WebExtensions Experiment proposal and I would like to get a proper view of the landscape.

    It’s pretty different from native.js which IMO was excellent in that it freed Firefox from the ties of deep reaching extensions, yet allowed add-on developers to still reach deep and surface a non-official API for other add-ons to use.

    Then, if this API is successful enough, Mozilla can implement it their own way into Firefox core without breaking add-ons that relied on it.

    Those API not successful enough would be allowed to survive with a guarantee that they will break often and it’s up to anyone willing to fix them, since it’s open source. The WebExtensions Advisory Group or some committee would ensure that not too many users in total rely on add-ons that use such rejected APIs, so things would not get out of hands.

    Correct me if I’m wrong but it seems that WE Experiments will:
    – Disallow non-official API developers to reach deep within Firefox no matter what
    – Kill non-official API that have been rejected for implementation within Firefox core.

    I fear this will:
    – Stifle innovation and flexibility
    – Prevent niche projects from being made to serve a small population such as, I don’t know, a CG-art community
    – Not free Firefox from the ties of deep reaching add-ons noticeably more than the native.js proposal.

    I wouldn’t mind hearing your thoughts on the topic.

    1. Andy McKay wrote on :

      I would recommend joining the dev-addons mailing list where this is being discussed: https://wiki.mozilla.org/Add-ons#Getting_in_touch

  4. Syed Faraz wrote on :

    A Great Improvement.

  5. jagan wrote on :

    how to remove primary adds from the mozilla firebox desktop