Mozilla Add-ons Community Blog
Firefox logo
Categories: developers releases webextensions

Extensions in Firefox 79

13 responses

We have a little more news this release: a new API method, a reminder about a recently announced change, a preview of some things to come, and a few interesting improvements. Let’s get started!

Warming up tabs

To optimize resource usage, render information on inactive tabs is discarded. When Firefox anticipates that a tab will be activated, the tab is “warmed up”. Switching to it then feels much more instantaneous. With the new tabs.warmup function, tab manager extensions will be able to benefit from the same perceived performance improvements. Note this API does not work on discarded tabs and does not need to be called immediately prior to switching tabs. It is merely a performance improvement when the tab switch can be anticipated, such as when hovering over a button that when clicked would switch to the tab.

Changes to storage.sync

We’ve blogged about this recently, but given this is part of Firefox 79 I wanted to make sure to remind you about the storage.sync changes we’ve been working on. Storage quotas for the storage.sync API are now being enforced as part of backend changes we’ve introduced for better scalability and performance.

There is no immediate action required if you don’t use the storage.sync API or are only storing small amounts of data. We encourage you to make your code resilient while your storage needs grow by checking for quota errors. Also, if you are getting support requests from users related to stored preferences you may want to keep this change in mind and support them in filing a bug as necessary.

For more information and how to file a bug in case you come across issues with this change, please see the blog post.

Firefox site isolation coming later this year

The Firefox platform team has been working on a new security architecture that isolates sites from each other, down to separating cross-origin iframes from the tab’s process. This new model, nicknamed Fission, is currently available for opt-in testing in Nightly. The platform team is planning to begin roll-out to Nightly and Beta users later this year.

So far, we have identified two changes with Fission enabled that will impact extensions:

  • Content scripts injecting extension iframes (from a moz-extension:// url) and accessing them directly via the contentWindow property will be incompatible with Fission, since that iframe will run in a different process. The recommended pattern, as always, is to use postMessage and extension messaging instead.
  • The synchronous canvas drawWindow API will be deprecated, since it’s unable to draw out-of-process iframes. You should switch to the captureTab method, which we are looking to extend with more functionality to provide a sufficient replacement.

If you are the developer of an extension that uses one of these features, we recommend that you update your extension in the coming months to avoid potential breakages.

We’re working to make the transition to Fission as smooth as possible for users and extension developers, so we need your help: please test your extensions with Fission enabled, and report any issues on Bugzilla as blocking the fission-webext meta bug. If you need help or have any questions, come find us on our community forum or Matrix.

We will continue to monitor changes that will require add-ons to be updated. We encourage you to subscribe to our blog to stay up to date on the latest developments. If more changes to add-ons are necessary we will reach out to developers individually or announce the changes here.

Miscellaneous

  • Extensions can use webRequest listeners to observe their own requests initiated by the downloads API.
  • The tabs.duplicate API now makes the tab active before resolving the promise, for parity with Chrome.
  • Disabling and re-enabling a WebExtension which provides a default search engine now correctly sets the engine as default again.

Special thanks in this release goes to community members Myeongjun Go, Sonia Singla, Deepika Karanji, Harsh Arora, and my friends at Mozilla that have put a lot of effort into making Firefox 79 successful. Also a special thanks to the Fission team for supporting us through the changes to the extension architecture. Stay tuned for next time!

13 comments on “Extensions in Firefox 79”

  1. Chris wrote on

    Can we please have TamperMonkey or some user script extension please.

    Currently there is no web browser which can open app links directly and run user script extensions.

    Kiwi Browser is based on an old version of chrome, which loads a google map in the browser first. Yandez browser always asks which app you want to open a map in, with no remember (plus it’s got a terrible UI), this browser would work – except it doesn’t have an extension to load user scripts.

  2. Juraj M. wrote on

    I like the new warmup API!
    Few questions:
    – will the “tabs.warmup” work on hidden tabs?
    – could you specify when is the promise resolved? Like what is happening behind the scene.
    – what’s the expected warmup time, can it be more than 200ms?

    1. Tomislav wrote on

      1) Yes I believe it will work on hidden tabs.
      2) Promise is resolved as soon the warmup() operation is initiated, but you don’t need to worry about it finishing, if you happen to switch to the tab before warmup is done, it will simply pause briefly, just as today (if you didn’t call warmup at all).
      3) I think the expected warmup is under 100ms, but it can very, and after about 400ms the tab is switched anyway and the spinner animation is shown instead.

  3. Robin wrote on

    “Content scripts injecting extension iframes (from a moz-extension:// url) and accessing them directly via the contentWindow property will be incompatible with Fission, since that iframe will run in a different process.”
    When I turn on Fission on Nightly this still works. Is there any other preference that needs to be changed or is there a bugzilla ticket which tracks this?

    1. Tomislav wrote on

      Right, parts of the platform are still in transition, so that still works, sort of. For easier testing, we’ll be adding a separate pref soon that will disable this kind of access independently from Fission, and you can follow that in bug 1644752.

  4. Daniel Nebdal wrote on

    Hi – I notice with very mixed feelings that Firefox (the base version, not nightly or beta) is now Fenix, which means that the new add-on system is the only alternative I have. It’s … not exactly a replacement.

    I had some smaller ones installed that may never get the lovingly hand-curated treatment that so far seems to be the only way in, and I don’t believe there is a way to sideload them, either. This all feels frustratingly patronising and proprietary.

  5. Janghou wrote on

    Dropping extension support on Firefox Android 79 is a real blow in the face.

    I have created several extensions that I COULD install locally on my phone (xpi) that is all finished.

    Among those:
    – weather `app`
    – control my DSLR, take and download photos to my phone over Wifi
    – MDP client (music daemon)
    – cookie-control
    – privacy app
    – medical log

    Hope that Firefox developers will at least add an option to install xpi soon, because most of them simply still work:

    web-ext run –target=firefox-android –android-device=XXXXX –firefox-apk=org.mozilla.firefox

    Please add an option for local install again. For the moment I can stick to the old ESR version of Firefox, but I’m really getting depressed by these kind of developments,

    Don’t tell me that telemetry (Mozilla knowing/controlling which extensions the user runs) is more important than the user, because at this moment, I feel the balance tilts to the wrong side.

    In general I’m’ losing confidence in `big tech` firms and the future. They own my phone, they control what I can do with it, I can only use it like the way they want with the software they control.

    That’s an inverted and totally scary future, I should own my phone and decide what software I run.

    Please add support again for install from file.

  6. Tobi wrote on

    “Disabling and re-enabling a WebExtension which provides a default search engine now correctly sets the engine as default again.”

    The process seems now broken with Firefox 79. Old WebExtensions with default search settings in manifest.json are overridden with browsers default setting (in most cases Google). Users have to switch manually in the settings to the extension search. Also disabling and re-enabling the extension doesn’t changes this, the extension default search is not active again, and has to be set manually.

    1. Caitlin Neiman wrote on

      Hi Tobi, it sounds like there might be a few issues there. Would you mind filing a bug at https://mzl.la/2kSVcB0 with the name of the extension and the steps to reproduce? We’d like to look into this further.

  7. Stefan wrote on

    Why is this not saying anything about the new shiny android firefox blocking almost all add-ons in the 79 release?
    This is a very important part of the roadmap!

    1. Daniel wrote on

      I want to be able to install any extension I want, how can I do that now?

  8. rudi wrote on

    How can i get ‘compact tabs’ (2 tabs in a row) as in previous version?

  9. David wrote on

    This sucks so much… The purpose of extensions is that anyone can add little features. And now you borked that for no apparent reason.

    Now I can choose to be stuck on an outdated version or lose lots of functionality.

    Why are you discarding the only real advantage that Firefox has?

    If I want a good browser with only ublock, I’d take Edge. Yes, it is that bad that even Edge is now the better alternative.