Featured

New extensions available now on Firefox for Android Nightly

Scott DeVaney

8 responses

As we continue to develop extensions support on Firefox for Android, we’re pleased to announce new additions to our library of featured Android extensions. To access featured extensions on Firefox for Android, tap Settings -> Add-ons.

Based on currently available APIs, performance evaluations, and listening to requests from the Mozilla community, here are five new extensions now available to Firefox for Android users…

Firefox Relay

Mozilla’s own Firefox Relay is now available for mobile usage. The extension lets you easily generate email masks that will forward messages to your authentic email while hiding your address from unwanted spam, or worse, hackers.

Tampermonkey on Android.

Tampermonkey

One of the most popular userscript managers makes its way to mobile. Tampermonkey top features include automatic update checks, an intuitive display of running scripts, plus browser and cloud storage sync.

Read Aloud: A Text to Speech Voice Reader

Have you ever wanted your news or other web pages (even PDF’s) read aloud so your hands and eyes are free to focus on other things? Read-Aloud: A Text to Speech Voice Reader can now accommodate you on Android — in 40+ languages.

AdNauseum

More than just an effective ad blocker, AdNauseum punches back against privacy invasive ad tech by clicking a bunch of blocked ads in the background so advertisers can’t build an accurate profile of your interests.

ClearURLs

A simple extension that provides a powerful privacy feature — ClearURLs automatically strips away tracking elements from web links you open.

Create extension collections on Firefox for Android Beta

By following these instructions you can now create your own custom extension collections on Firefox for Android Beta (previously, collections were only available on Nightly). Name the collection anything you like, so long as there aren’t any spaces in its title. When creating your collection, you’ll see a number in the Custom URL field; this is your user ID. You’ll need the collection name and user ID to configure Beta in the following way:

Once created, simply add extensions to your collection. Each collection generates a custom URL so you’re to share it with others.

Are more extensions coming to Firefox for Android?

Absolutely. Right now we’re focused on implementing Manifest version 3 (MV3) for Firefox desktop (i.e. wide ranging foundational changes to WebExtensions API). In 2023 we’ll begin work on the mobile adoption of MV3. Though we’re still early in planning, MV3 will certainly offer a number of advances for mobile extensions, such as elegant handling of process restarts and improved security by splitting extensions into their own processes, while also retaining critical MV2 features that support privacy and ad blocking capabilities. Indeed our goal is to design MV3 for mobile in such a manner we’re able to open up the discoverability of mobile extensions beyond the short list available today. As plans take shape, we’ll be sure to keep you informed. In the meantime you’re welcome to join conversations about extensions development on Firefox Add-ons Discourse.

 

Manifest v3 signing available November 21 on Firefox Nightly

Shane Caraveo

11 responses

Starting November 21, 2022 add-on developers are welcome to upload their Firefox Manifest version 3 (MV3) compatible extensions to addons.mozilla.org (AMO) and have them signed as MV3 extensions. Getting an early jump on MV3 signing enables you to begin testing your extension’s future functionality on Nightly to ensure a smooth eventual transition to MV3 in Firefox.

To be clear, Firefox will continue to support MV2 extensions for the foreseeable future, even as we welcome MV3 extensions in the release to general availability in Firefox 109 (January 17, 2023). Our goal has been to ensure a seamless transition from MV2 to MV3 for extension developers. Taking a gradual approach and gathering feedback as MV3 matures, we anticipate opportunities will emerge over time to modify our initial MV3 offering. In these instances, we intend to take the time necessary to make informed decisions about our approach.

Towards the end of 2023 — once we’ve had time to evaluate and assess MV3’s rollout (including identifying important MV2 use cases that will persist into MV3) — we’ll decide on an appropriate timeframe to deprecate MV2. Once this timeframe is established, we’ll communicate MV2’s closure process with advance notice. For now, please see this guide for supporting both MV2 and MV3 versions of your extension on AMO.

Mozilla’s vision for Firefox MV3

Firefox MV3 offers simplified and consolidated APIs, enhanced security and privacy mechanisms, and functionality to better support mobile platforms. As we continue to collaborate with other browser vendors and the developer community to shape MV3, we recognize cross-browser compatibility as a fundamental consideration. That said, we’re also implementing distinct elements to suit Firefox’s product and community needs. We want to give extension developers creative flexibility and choice, while ensuring users maintain access to the highest standards of extension customization and security. Firefox MV3 stands apart from other iterations of MV3 in two critical ways:

  1. While other browser vendors introduced declarativeNetRequest (DNR) in favor of blocking Web Request in MV3, Firefox MV3 continues to support blocking Web Request and will support a compatible version of DNR in the future. We believe blocking Web Request is more flexible than DNR, thus allowing for more creative use cases in content blockers and other privacy and security extensions. However, DNR also has important performance and compatibility characteristics we want to support.
  2. Firefox MV3 offers Event Pages as the background script in lieu of service workers, though we plan to support service workers in the future for compatibility. Event Pages offer benefits like DOM and Web APIs that aren’t available to service workers, while also generally providing a simpler migration path.

Over subsequent releases next year, we’ll continue to expand Firefox MV3 compatibility.

MV3 also ushers an exciting user interface change in the form of the new extensions button (already available on Firefox Nightly). This will give users direct control over which extensions can access specific web sites.

The extensions button will give Firefox users direct control over website specific extension permissions.

Users are able to review, grant, or revoke MV3 extension access to any website. MV2 extensions will display in the button interface, but permissions access is unavailable. Please see this post for more information about the new extensions button.

If you’re planning to migrate your MV2 extension to MV3, there are steps you can take today to get started. We always encourage feedback from our developer community, so don’t hesitate to get in touch:

Extensions button and how to handle permissions in Manifest V3

Juha-Matti Santala

39 responses

Manifest V3 (MV3) is bringing new user-facing changes to Firefox, including an extensions button to manage installed and enabled browser extension permissions (origin controls), providing Firefox users control over extension access to their browsers. The first building blocks of this button were added to Nightly in Firefox 107 and will become available with the general release of MV3 in Firefox 109.

Extensions button

The extensions button will give Firefox users direct control over website specific extension permissions.

In MV2, host permissions are granted by the user at the time of install and there’s no elegant way for the user to change this setting (short of uninstalling/reinstalling and choosing different permissions). But with the new extensions button in MV3 in Firefox, users will have easy access and persistent control over which extensions can access any web page, at any time. Users are free to grant ongoing access to a website, or make a choice per visit. To enable this, MV3 treats host permissions (listed in the extension manifest) as opt-in.

The button panel will display the user’s installed and enabled extensions and their current permission state. In addition to managing host permissions, the panel also allows the user to manage, remove, or report the extension. Extensions with browser actions will behave similarly in the toolbar as in the panel.

Manifest V2 (MV2) extensions will also display in the panel; however users can’t take actions for MV2 host permissions since those were granted at installation and this choice cannot be reversed in MV2 without uninstalling the extension and starting again.

You can also find more information about the extensions button from support.mozilla.org

How to deal with opt-in permissions in extension code

The Permissions API provides a way for developers to read and request permissions.

With permissions.request(), you can request specific permissions that have been defined as optional permissions in the manifest:

const permissionsToRequest = {
  permissions: ["bookmarks", "history"],
  origins: ["https://developer.mozilla.org/"]
}

async function requestPermissions() {
  function onResponse(response) {
    if (response) {
      console.log("Permission was granted");
    } else {
      console.log("Permission was refused");
    }

    return browser.permissions.getAll();
  }

  const response = await browser.permissions.request(permissionsToRequest);
  const currentPermissions = await onResponse(response);

  console.log(`Current permissions:`, currentPermissions);
}

This is handy when the request for permissions is tied to a user action like selecting a context menu item. Note that you cannot request for a permission that is not defined in the manifest.

Other times, you’ll want to react to a permission being granted or removed. This can be done with permissions.onAdded and permissions.onRemoved respectively.


function handleAdded(permissions) {
  console.log(`New API permissions: ${permissions.permissions}`);
  console.log(`New host permissions: ${permissions.origins}`);
}

browser.permissions.onAdded.addListener(handleAdded);

Finally, you can check for already existing permissions in two different ways: permissions.getAll() returns a list of all granted permissions and permissions.contains(permissionsToCheck) checks for specific permissions and resolves to true if, and only if, all checked permissions are granted.


// Extension permissions are:
// "webRequest", "tabs", "*://*.mozilla.org/*"

let testPermissions1 = {
  origins: ["*://mozilla.org/"],
  permissions: ["tabs"]
};

const testResult1 = await browser.permissions.contains(testPermissions1);
console.log(testResult1); // true

We always encourage feedback from our developer community, so don’t hesitate to get in touch:

Begin your MV3 migration by implementing new features today

Shane Caraveo

21 responses

Early next year, Firefox will release Mozilla’s Manifest V3 (MV3). Therefore, it’s an ideal time to consider migrating your Manifest V2 extensions. One of our goals throughout our approach to MV3 has been to gradually release new WebExtensions features that enable you to begin implementing APIs that are compatible with MV3. To this end, we recently released some exciting new features you should know about…

 

MV3 changes you can make to your extension right now

 

Event Pages

In Firefox MV3, we’re providing Event Pages as the background script. Event Pages retain several important features, including access to DOM and WebAPIs that are not available with the new service worker backgrounds used in Google Chrome.

We enabled Event Pages for MV2 (aka non-persistent background pages that can be closed and respawned based on browser events) in Firefox 106. This update is a major step toward MV3 because all extensions must adopt Event Pages in MV3. But you can make this change today and use new Event Pages benefits such as:

  • Resiliency against unexpected system crashes. Now we can restart a corrupted background page without hindering the user.
  • No need for an extension reboot to reset a background page.
  • Save on memory resources by putting idle background pages to sleep.

How do I implement Event Pages?

To turn your background into an Event Page, set `persistent: false` on the background page in your manifest.json. Here’s more info on background scripts with implementation details.

Now that your background script is non-persistent, you need to tell Firefox when to wake up the page if it’s suspended. There are two methods available:

  1. Use an event listener like `browser.tabs.onCreated` in your background script.  Event listeners must be added at the top level execution of your script. This way, if your background is sleeping Firefox knows to wake the script whenever a new tab is spawned. This works with nearly all events in the WebExtensions API. Here’s more info on adding listeners. (Note that Firefox recognizes arguments passed to addListener and does not create multiple listeners for the same set of arguments.)
  2. Use `browser.runtime.getBackgroundPage` if you need a background page to run processes unrelated to events. For instance, you may need a background script to run a process while the user is involved with a browser action or side panel. Use this API anytime you need direct access to a background page that may be suspended or closed. Here’s more info on background script functions.

Menus and Scripting APIs also support persistent data:

  • Menu items created by an event page are available after they’re registered — even if the event page is terminated. The event page respawns as necessary to menu events.
  • Registered scripts can be injected into matching web pages without the need for a running Event Page.

Scripting

You can take another big step toward MV3 by switching to the new Scripting API. This API consolidates several scripting related APIs — contentScripts.register(), tabs.insertCSS(), tabs.removeCSS(), and tabs.executeScript() — and adds capabilities to register, update, and unregister content scripts at runtime.

Also, arbitrary strings can no longer be executed because the code parameter has been removed. So you’ll need to move any arbitrary strings executed as scripts into files contained within the extension, or to the func property used with, if necessary, the args parameter.

This API requires the scripting permission.

Preparing for MV3 restrictions

MV3 will impose enhanced restrictions on several features. Most of these restrictions are outlined in the MV3 migration guide. By following the steps detailed in the guide, there are some ways you can begin modifying your MV2 extension to make it comply more closely with MV3 requirements. A few noteworthy areas include…

Conform to MV3’s Content Security Policy

Mozilla’s long-standing add-on policies prohibit remote code execution. In keeping with these policies, the content_security_policy field no longer supports sources permitting remote code in script-related directives, such as script-src or `’unsafe-eval’`. The only permitted values for the `script-src` directive is `’self’` and `’wasm-unsafe-eval’`. `’wasm-unsafe-eval’` must be specified in the CSP if an extension wants to use WebAssembly. In MV3, content scripts are subject to the same CSP as other parts of the extension.

Historically, a custom extension CSP required object-src to be specified. This is not required in MV3 and was removed from MV2 in Firefox 106 (see object-src in content_security_policy on MDN). This change makes it easier for extensions to customize the CSP with minimal boilerplate.

The Content Security Policy (CSP) is more restrictive in MV3. If you are using a custom CSP in your MV2 add-on, you can validate the CSP by temporarily running it as an MV3 extension.  See the MV3 migration guide for details.

Upgrade insecure requests – https by default

When communicating with external servers, extensions will use https by default. Extensions should replace the “http:” and ”ws:” schemes in their source code with secure alternatives, “https:” and ”wss:”. The default MV3 CSP includes the upgrade-secure-requests directive, to enforce the use of secure schemes even if an insecure scheme was used.

Extensions can opt out of this https requirement by overriding the content_security_policy and omitting the upgrade-secure-requests, provided that no user data is transmitted insecurely through the extension.

Opt-in permissions

All MV3 permissions, including host permissions, are opt-in for users. This necessitated a significant Firefox design change — the introduction of the extensions button — so users can easily grant or deny website specific permissions at any time (the button is enabled on Firefox Nightly for early testing and feedback).

The extensions button gives Firefox users direct control over website specific extension permissions.

Therefore, you must ensure your extension has permission whenever it accesses APIs covered by a permission, accesses a tab, or uses Fetch API. MV2 already has APIs that enables you to check for permissions and watch for changes in permission. When necessary, you can get the current permission status. However, rather than always checking, use the permissions.onAdded and permissions.onRemoved event APIs to watch for changes.

Update content scripts

While content scripts continue to have access to the same extension APIs in MV3 as in MV2, most of the special exceptions and extension specific capabilities have been removed from the web platform APIs (DOM APIs). In particular, the extension’s host permissions no longer apply to Fetch and XMLHttpRequest.

CSP for content scripts

With MV2 no CSP is applied to content scripts. In MV3, content scripts are subjected to the same CSP as other parts of the extension (see CSP for content scripts on MDN). Notably, this means that remote code cannot be executed from the content script. Some existing uses can be replaced with functionality from the Scripting API such as func and args (see the “Scripting” section above), which is available to MV2 extensions.

XHR and Fetch

With MV2 you also have access to some APIs, such as XMLHttpRequest and Fetch, from both extension and web page contexts. This allows for cross origin requests in a way that is not available in MV3. In MV3, XHR and Fetch operate as if the web page itself was using them, and are subject to cross origin controls.

Content scripts can continue using XHR and Fetch by first making requests to background scripts. A background script can then use Fetch to get the data and return the necessary information to the content script. To avoid privacy issues, set the “credentials” option to “omit” and cache option to “no-cache”. In the future, we may offer an API to support the make-request-on-behalf-of-a-document-in-a-tab use case.

Will Chrome MV3 extensions work in Firefox MV2?

The release of MV3 in Firefox is distinct from Chrome. Add-ons intended to work across different browsers will, in most cases, require some level of adjustment to be compatible in both Firefox and Chrome. That said, we are committed to a high level of compatibility. We will be providing additional APIs and features in the near future. If you’ve converted your Chrome extension to Google’s MV3, you may be able to consolidate some of those changes into your Firefox MV2 extension. Here are a few areas to investigate:

  • Service Workers are not yet available in Firefox; however many scripts may work interchangeably between Service Workers and Event Pages, depending on functionality. To get things working, you may need to remove service worker specific APIs. See Service Worker Global Scope for more information.
  • DNR is not yet available in Firefox. Firefox retains WebRequest blocking in MV3, which can be used in place of DNR. When DNR is available, simple request modifications can be moved over to DNR.
  • The storage.session API is not yet available in Firefox. You can use other storage mechanisms in the meantime.

Hopefully, we’ve provided helpful information so you can use the new MV2 features to start your migration to MV3. As always, we appreciate your feedback and welcome questions. Here are the ways to get in touch:

Hello from the new developer advocate

Juha-Matti Santala

12 responses

Hello extension developers, I’m Juhis, it’s a pleasure to meet you all. In the beginning of August I joined Mozilla and the Firefox add-ons team as a developer advocate. I expect us to see each other quite a lot in the future. My mom taught me to always introduce myself to new people so here we go!

My goal is to help all of you to learn from each other, to build great add-ons and to make that journey an enjoyable experience. Also, I want to be your voice to the teams building Firefox and add-ons tooling.

My journey into the world of software

I’m originally from Finland and grew up in a rather small town in the southwest. I got excited about computers from a very young age. I vividly remember a moment from my childhood when my sister created a digital painting of two horses, but since it was too large for the screen, I had to scroll to reveal the other horse. That blew my four-year old mind and I’ve been fascinated by the opportunities of technology ever since.

After some years working in professional software development, I realized I could offer maximum impact by building communities and helping others become developers rather than just coding myself. Ever since, I’ve been building developer communities, organized meetups, taught programming and served as a general advocate for the potentials of technology.

I believe in the positive empowerment that technology can bring to individuals all around the world. Whether it’s someone building something small to solve a problem in their daily life, someone building tools for their community, or being able to build and run your own business, there are so many ways we can leverage technology for good.

Customize your own internet experience with add-ons

The idea of shaping your own internet experience has been close to my heart for a long time. It can be something relatively simple like running custom CSS through existing extensions to make a website more enjoyable to use, or maybe it’s building big extensions for thousands of other people to enjoy. I’m excited to now be in a position where I can help others to build great add-ons of their own.

To understand better what a new extensions developer goes through, I built an extension following our documentation and processes. I built it for fellow Pokemon TCG players who want a a more visual way to read decklists online. Pokemon TCG card viewer can be installed from addons.mozilla.org. It adds a hover state to card codes it recognizes and displays a picture of the card on hover.

Best way to find me is in the Mozilla Matrix server as @hamatti:mozilla.org in the Add-ons channel. Come say hi!

Tags:

Categories: Uncategorized

Manifest V3 Firefox Developer Preview — how to get involved

Shane Caraveo

3 responses

While MV3 is still in development, many major features are already included in the Developer Preview, which provides an opportunity to expose functionality for testing and feedback. With strong developer feedback, we’re better equipped to quickly address critical bug fixes, provide clear developer documentation, and reorient functionality.

Some features, such as a well defined and documented lifecycle for Event Pages, are still works in progress. As we complete features, they’ll land in future versions of Firefox and you’ll be able to test and progress your extensions into MV3 compatibility. In most ways Firefox is committed to MV3 cross browser compatibility. However, as explained in Manifest V3 in Firefox: Recap & Next Steps, in some cases Firefox will offer distinct extension functionality.

Developer Preview is not available to regular users; it requires you to change preferences in about:config. Thus you will not be able to upload MV3 extensions to addons.mozilla.org (AMO) until we have an official release available to users.

The following are key considerations about migration at this time and areas we’d greatly appreciate developer feedback.

  1. Read the MV3 migration guide. MV3 contains many changes and our migration guide covers the major necessary steps, as well as linking to documentation to help understand further details.
  2. Update your extension to be compatible with Event Pages. One major difference in Firefox is our use of Event Pages, which provides an alternative to the existing Background Pages that allows idle timeouts and page restarts. This adds resilience to the background, which is necessary for resource constraints and mobile devices. For the most part, Event Pages are compatible with existing Background Pages, requiring only minor changes. We plan to release Event Pages for MV2 in an upcoming Firefox release, so preparation to use Event Pages can be included in MV2 addons soon. Many extensions may not need all the capabilities available in Event Pages. The background scripts are easily transferable to the Service Worker background when it becomes available in a future release. In the meantime, extensions attempting to support both Chrome and Firefox can take advantage of Event Pages in Firefox.
  3. Test your content scripts with MV3. There are multiple changes that will impact content scripts, ranging from tighter restrictions on CORS, CSP, remote code execution, and more. Not all extensions will run into issues in these cases, and some may only require minor modifications that will likely work within MV2 as well.
  4. Understand and consider your migration path for APIs that have changed or deprecated. Deprecated APIs will require code changes to utilize alternate or new APIs. Examples include New Scripting API (which will be part of MV2 in a future release), changing page and browser actions to the action API, etc.
  5. Test and plan migration for permissions. Most permissions are already available as optional permissions in MV2. With MV3, we’re making host permissions optional — in many cases by default. While we do not yet have the primary UI for user control in Developer Preview, developers should understand how these changes will affect their extensions.
  6. Let us know how it’s going! Your feedback will help us make the transition from MV2 to MV3 as smooth as possible. Through Developer Preview we anticipate learning about MV3 rough edges, documentation needs, new features to be fleshed out, and bugs to be fixed. We have a host of community channels you can access to ask questions, help others, report problems, or whatever else you desire to communicate as it relates to the MV3 migration process.

Stay in touch with us on any of these forums…

 

Manifest v3 in Firefox: Recap & Next Steps

Rob Wu

12 responses

It’s been about a year since our last update regarding Manifest v3. A lot has changed since then, not least of which has been the formation of a community group under the W3C to advance cross-browser WebExtensions (WECG).

In our previous update, we announced that we would be supporting MV3 and mentioned Service Workers as a replacement for background pages. Since then, it became apparent that numerous use cases would be at risk if this were to proceed as is, so we went back to the drawing board. We proposed Event Pages in the WECG, which has been welcomed by the community and supported by Apple in Safari.

Today, we’re kicking off our Developer Preview program to gather feedback on our implementation of MV3. To set the stage, we want to outline the choices we’ve made in adopting MV3 in Firefox, some of the improvements we’re most excited about, and then talk about the ways we’ve chosen to diverge from the model Chrome originally proposed.

Why are we adopting MV3?

When we decided to move to WebExtensions in 2015, it was a long term bet on cross-browser compatibility. We believed then, as we do now, that users would be best served by having useful extensions available for as many browsers as possible. By the end of 2017 we had completed that transition and moved completely to the WebExtensions model. Today, many cross-platform extensions require only minimal changes to work across major browsers. We consider this move to be a long-term success, and we remain committed to the model.

In 2018, Chrome announced Manifest v3, followed by Microsoft adopting Chromium as the base for the new Edge browser. This means that support for MV3, by virtue of the combined share of Chromium-based browsers, will be a de facto standard for browser extensions in the foreseeable future. We believe that working with other browser vendors in the context of the WECG is the best path toward a healthy ecosystem that balances the needs of its users and developers. For Mozilla, this is a long term bet on a standards-driven future for WebExtensions.

Why is MV3 important to improving WebExtensions?

Manifest V3 is the next iteration of WebExtensions, and offers the opportunity to introduce improvements that would otherwise not be possible due to concerns with backward compatibility. MV2 had architectural constraints that made some issues difficult to address; with MV3 we are able to make changes to address this.

One core part of the extension architecture is the background page, which lives forever by design. Due to memory or platform constraints (e.g. on Android), we can’t guarantee this state, and termination of the background page (along with the extension) is sometimes inevitable. In MV3, we’re introducing a new architecture: the background script must be designed to be restartable. To support this, we’ve reworked existing and introduced new APIs, enabling extensions to declare how the browser should behave without requiring the background script.

Another core part of extensions are content scripts, to directly interact with web pages. We are blocking unsafe coding practices and are offering more secure alternatives to improve the base security of extensions: string-based code execution has been removed from extension APIs. Moreover, to improve the isolation of data between different origins, cross-origin requests are no longer possible from content scripts, unless the destination website opts in via CORS.

User controls for site access

Extensions often need to access user data on websites. While that has enabled extensions to provide powerful features and address numerous user needs, we’ve also seen misuse that impacts user’s privacy.

Starting with MV3, we’ll be treating all site access requests from extensions as optional, and provide users with transparency and controls to make it easier to manage which extensions can access their data for each website.

At the same time, we’ll be encouraging extensions to use models that don’t require permanent access to all websites, by making it easier to grant access for extensions with a narrow scope, or just temporarily. We are continuing to evaluate how to best handle cases, such as privacy and security extensions, that need the ability to intercept or affect all websites in order to fully protect our users.

What are we doing differently in Firefox?

WebRequest

One of the most controversial changes of Chrome’s MV3 approach is the removal of blocking WebRequest, which provides a level of power and flexibility that is critical to enabling advanced privacy and content blocking features. Unfortunately, that power has also been used to harm users in a variety of ways. Chrome’s solution in MV3 was to define a more narrowly scoped API (declarativeNetRequest) as a replacement. However, this will limit the capabilities of certain types of privacy extensions without adequate replacement.

Mozilla will maintain support for blocking WebRequest in MV3. To maximize compatibility with other browsers, we will also ship support for declarativeNetRequest. We will continue to work with content blockers and other key consumers of this API to identify current and future alternatives where appropriate. Content blocking is one of the most important use cases for extensions, and we are committed to ensuring that Firefox users have access to the best privacy tools available.

Event Pages

Chrome’s version of MV3 introduced Background Service Worker as a replacement for the (persistent) Background Page. Mozilla is working on extension Service Workers in Firefox for compatibility reasons, but also because we like that they’re an event-driven environment with defined lifetimes, already part of the Web Platform with good cross-browser support.

We’ve found Service Workers can’t fully support various use cases we consider important, especially around DOM-related features and APIs. Additionally, the worker environment is not as familiar to regular web developers, and our developer community has expressed that completely rewriting extensions can be tedious for thousands of independent developers of existing extensions.

In Firefox, we have decided to support Event Pages in MV3, and our developer preview will not include Service Workers (we’re continuing to work on supporting these for a future release). This will help developers to more easily migrate existing persistent background pages to support MV3 while retaining access to all of the DOM related features available in MV2. We will also support Event Pages in MV2 in an upcoming release, which will additionally aid migration by allowing extensions to transition existing MV2 extensions over a series of releases.

Next Steps for Firefox

In launching our Developer Preview program for Manifest v3, our hope is that authors will test out our MV3 implementation to help us identify gaps or incompatibilities in our implementation. Work is continuing in parallel, and we expect to launch MV3 support for all users by the end of 2022. As we get closer to completion, we will follow up with more detail on timing and how we will support extensions through the transition.

For more information on the Manifest v3 Developer Preview, please check out the migration guide.  If you have questions or feedback on Manifest v3, we would love to hear from you on the Firefox Add-ons Discourse.

A new API for submitting and updating add-ons

Andrew Williamson

6 responses

The addons.mozilla.org (AMO) external API has offered add-on developers the ability to submit new add-on versions for signing for a number of years, in addition to being available to get data about published add-ons directly or internally inside Firefox.

Current “signing” API

Currently, the signing api offers some functionality, but it’s limited – you can’t submit the first listed version of an add-on (extra metadata is needed to be collected via developer hub); you can’t edit existing submissions; you can’t submit/edit extra metadata about the add-on/version; and you can’t share the source code for an add-on when it’s needed to comply with our policies. For all of those tasks you need to use the forms on the appropriate developer hub web pages.

New Add-on “submission” API

The new add-on submission api aims to overcome these limitations and (eventually) allow developers to submit and manage all parts of their add-on via the API. It’s available now in our v5 api, and should be seen as beta quality for now.

Submission Workflow

The submission workflow is split by the process of uploading the file for validation, and attaching the validated file to a new add-on, or as a new version to an existing add-on.

  1. The add-on file to be distributed is uploaded via the upload create endpoint, along with the channel, returning an upload uuid.
  2. The upload detail endpoint can be polled for validation status.
  3. Once the response has "valid": true, it can be used to create either a new add-on, or a new version of an existing add-on. Sources may be attached if required.

Uploading the add-on file

Regardless of if you are creating a new add-on or adding a new version to an existing add-on, you will need to upload the file for validation first. Here you will decide if the file will be associated with a public listing (listed), or will be self-hosted (unlisted). See our guide on signing and distribution for further details.

# Send a POST request to the upload create endpoint
# Pass addon.xpi as a file using multipart/form-data, along with the
# distribution channel.
curl -XPOST "https://addons.mozilla.org/api/v5/addons/upload/" \
  -H "Authorization: <JWT blob>" \
  -F "upload=@addon.xpi" -F "channel=listed"

The response will provide information on successful validation, if valid is set to true you will be able to use the uuid in the next submission steps. The recommended polling interval is 5-10 seconds, making sure your code times out after a maximum of 10 minutes.

Creating a new add-on

When creating a new add-on, we require some initial metadata to describe what the add-on does, as well as some optional fields that will allow you to create an appealing listing. Make a request to the add-ons create endpoint to attach the uploaded file to a new add-on:

# Send a POST request to the add-ons create endpoint
# Include the add-on metadata as JSON.
curl -XPOST "https://addons.mozilla.org/api/v5/addons/addon/" \
  -H "Authorization: <JWT blob>" \
  -H "Content-Type: application/json" -d @- <<EOF
{
  "categories": {
    "firefox": ["bookmarks"]
  },
  "summary": {
    "en-US": “This add-on does great things!”
  },
  "version": {
    "upload": "<upload-uuid>",
    "license": "MPL-2.0"
  }
}
EOF

When submitting to the self-hosted channel, you can omit extra metadata such as categories, summary or license.

Adding a version to an existing add-on

If instead you are  adding a version to an existing add-on, the metadata has already been provided in the initial submission. The following request can be made to attach the version to the add-on:

# Send a POST request to the versions create endpoint.
# Include the upload uuid from the previous add-on upload
curl -XPOST "https://addons.mozilla.org/api/v5/addons/addon/<add-on id>/versions/" \
  -H "Authorization: <JWT blob>" -H "Content-Type: application/json" \
  -d '{ "upload": <upload-uuid> }'

Updating existing add-on or version metadata

Metadata on any existing add-ons or versions can be updated, regardless of how they have been initially submitted. To do so, you can use the add-on edit or version edit endpoints. For example:

# Send a PATCH request to the add-ons edit endpoint
# Set the slug and tags as JSON data.
curl -XPATCH "https://addons.mozilla.org/api/v5/addons/addon/<add-on id>/" \ \
  -H "Authorization: <JWT blob>" -H "Content-Type: application/json" \
  -d @- <<EOF
{
  "slug": "new-slug",
  "tags": ["chat", "music"]
}
EOF

Providing Source code

When an add-on/version submission requires source code to be submitted it can either be uploaded while creating the version, or as an update to an existing version.  Files are always uploaded as multipart/form-data rather than JSON so setting source can’t be combined with every other field.

# Send a PATCH request to the version edit endpoint
# Pass source.zip as a file using multipart/form-data, along with the license field.
curl -XPATCH "https://addons.mozilla.org/api/v5/addons/addon/<add-on id>/versions/<version-id>/"  \
  -H "Authorization: <JWT blob>" \
  -F "source=@source.zip" -F "license=MPL-2.0"

You may also provide the source code as part of adding a version to an existing add-on. Fields such as compatibility, release_notes or custom_license can’t be set at the same time because complex data structures (lists and objects) can only be sent as JSON.

# Send a POST request to the version create endpoint
# Pass source.zip as a file using multipart/form-data,
# along with the upload field set to the uuid from the previous add-on upload.
curl -XPOST "https://addons.mozilla.org/api/v5/addons/addon/<add-on id>/versions/" \
  -H "Authorization: <JWT blob>" \
  -F "source=@source.zip" -F "upload=500867eb-0fe9-47cc-8b4b-4645377136b3"

 

Future work and known limitations

There may be bugs – if you find any please file an issue! – and the work is still in progress, so there are some known limitations where not all add-on/version metadata that is editable via developer hub can be changed yet, such as adding/removing add-on developers, or uploading icons and screenshots.

Right now the web-ext tool (or sign-addon) doesn’t use the new submission API (they use the signing api); updating those tools is next on the roadmap.

Longer term we aim to replace the existing developer hub and create a new webapp that will use the add-on submission apis directly, and also deprecate the existing signing api, leaving a single method of uploading and managing all add-ons on addons.mozilla.org.

New JavaScript syntax support in add-on developer tools

William Durand

3 responses

It’s been a year since we last added support for new JavaScript syntax to the add-ons linter. In that time we’ve used it to validate over 150,000 submissions to AMO totalling hundreds of millions of lines of code. But it has been a year, and with both Javascript and Firefox are constantly and quickly evolving, the list of JavaScript features Firefox supports and what the AMO linter allows have drifted apart.

This drift is not an accident; Firefox and AMO don’t keep the same cadence on supported features, and this is deliberate. Upcoming JavaScript features are spread across different EcmaScript proposal stages, meaning different features are always in different stages of readiness. While Firefox often trials promising new JavaScript features that aren’t “finished” yet (stage 4 in the ECMAScript process) to better test their implementations and drive early adoption, the AMO team takes a different approach intended to minimize friction developers might face moving their addons between browsers. To that end, the AMO team only adds support for “finished”, stage 4 features to the linter.

This hybrid approach works well for everyone; while Firefox continues to push the web ecosystem forward, AMO is making it easier for add-on developers to move laterally within that ecosystem.

Today, we’re happy to announce that our linter has been updated to ESLint v8 for JavaScript validation. This upgrades linter support to ECMAScript 2022 syntax, including features like public field declaration and top-level await that add-on developers will find particularly useful.

If you’d like to know more about how these tools work, and maybe help us improve them, bug reports and new contributors are always welcome. Thank you for being a part of Mozilla, and the add-ons developer community.

Add-on Policy Changes 2021

Philipp Kewisch

Update: The policies are now live, please see the main policy for details.

From time to time, the Add-ons Team makes changes to the policies in order to provide more clarity for developers, improve privacy and security for users, and to adapt to the evolving needs of the ecosystem. Today we’d like to announce another such update, to make sure the Add-ons developer community is well-prepared for when we start to enforce them on December 1st, 2021.

In this update, we’ve put a major focus on clarity and accessibility, taking a holistic view of our policies and making them as easy to understand and navigate as possible. While this has resulted in a substantially rewritten and reorganized document, the policy changes are modest and unlikely to surprise anyone. The most notable changes that may require action on the part of add-on developers are as follows:

  • Collecting browsing activity data, such as visited URLs, history, associated page data or similar information, is only permitted as part of an add-on’s primary function. Collecting user data or browsing information secretively remains prohibited.
  • Add-ons that serve the sole purpose of promoting, installing, loading or launching another website, application or add-on are no longer permitted to be listed on addons.mozilla.org.
  • Encryption – standard, in-browser HTTPS – is now always required when communicating with remote services. In the past, this was only required when transporting sensitive information.
  • The section on cookie policies has been removed, and providing a consent experience for accessing cookies is no longer required. Note however, that if you use cookies to access or collect technical data, user interaction data or personal data, you will still require a consent experience at first run of the add-on.

The remaining changes in the document focus on improving the clarity, discoverability and examples. While the policies have not substantially changed, it will be worth your time to review them.

  • If your add-on collects technical data, user interaction data, or personal data, you must show a consent experience at the first run of the add-on. This update improves our description of these requirements, and we encourage you to review both the requirements and  our recommended best practices for implementing them.
  • There are certain types of prohibited data collection. We do this to ensure user privacy and to avoid add-ons collecting more information than necessary, and in this update we’ve added a section describing the types of data collection that fall under this requirement.
  • Most add-ons require a privacy policy. For add-ons listed on addons.mozilla.org, the policy must be included in the listing in its full text. We’ve created a section specific to the privacy policy that lays out these requirements in more detail.
  • If your add-on makes use of monetization, the monetization practices must adhere to the data collection requirements in the same way the add-on does. While we have removed duplicate wording from the monetization section, the requirements have not changed and we encourage you to review them as well.