A new API for submitting and updating add-ons

Firefox

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 need 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: " 
  -F "source=@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: " 
  -H "Content-Type: application/json" -d @- <<EOF
{
  "categories": {
    "firefox": ["bookmarks"]
  },
  "summary": {
    "en-US": “This add-on does great things!”
  },
  "version": {
    "upload": "",
    "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//versions/" 
  -H "Authorization: " -H "Content-Type: application/json" 
  -d '{ "upload":  }'

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//"  
  -H "Authorization: " -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//versions//"  
  -H "Authorization: " 
  -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//versions/" 
  -H "Authorization: " 
  -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.

The post A new API for submitting and updating add-ons appeared first on Mozilla Add-ons Community Blog.

New JavaScript syntax support in add-on developer tools

Firefox

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.

The post New JavaScript syntax support in add-on developer tools appeared first on Mozilla Add-ons Community Blog.

Add-on Policy Changes 2021

Firefox

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.

You can preview the policy and ensure your extensions abide by them to avoid any disruption. If you have questions about these updated policies or would like to provide feedback, please post to this forum thread.

The post Add-on Policy Changes 2021 appeared first on Mozilla Add-ons Community Blog.

Thank you, Recommended Extensions Community Board!

Firefox

Given the broad visibility of Recommended extensions across addons.mozilla.org (AMO), the Firefox Add-ons Manager, and other places we promote extensions, we believe our curatorial process should include a wide range of perspectives from our global community of contributors. That’s why we have the Recommended Extensions Advisory Board—an ongoing project that involves a rotating group of contributors to help identify and evaluate new extension candidates for the program.

Our most recent community board just completed their six-month project and I’d like to take a moment to thank Sylvain Giroux, Jyotsna Gupta, Chandan Baba, Juraj Mäsiar, and Pranjal Vyas for sharing their time, passion, and knowledge of extensions. Their insights helped usher a wave of new extensions into the Recommended program, including really compelling content like I Don’t Care About Cookies (A+ cookie manager), Tab Stash (highly original take on tab management), Custom Scrollbars (neon colored scrollbar? Yes please!), PocketTube (great way to organize a bunch of YouTube subscriptions), and many more. 

On behalf of the entire Add-ons staff, thank you and all!

Now we’ll turn our attention to forming the next community board for another six-month project dedicated to evaluating new Recommended candidates. If you have a passion for browser extensions and you think you could make an impact contributing your insights to our curatorial process, we’d love to hear from you by Monday, 30 August. Just drop us an email at amo-featured [at] mozilla.org along with a brief note letting us know a bit about your experience with extensions—whether as a developer, user, or both—and why you’d like to participate on the next Recommended Extensions Community Advisory Board.

The post Thank you, Recommended Extensions Community Board! appeared first on Mozilla Add-ons Community Blog.

New tagging feature for add-ons on AMO

There are multiple ways to find great add-ons on addons.mozilla.org (AMO). You can browse the content featured on the homepage, use the top navigation to drill down into add-on types and categories, or search for specific add-ons or functionality. Now, we’re adding another layer of classification and opportunities for discovery by bringing back a feature called tags.

We introduced tagging long ago, but ended up discontinuing it because the way we implemented it wasn’t as useful as we thought. Part of the problem was that it was too open-ended, and anyone could tag any add-on however they wanted. This led to spamming, over-tagging, and general inconsistencies that made it hard for users to get helpful results.

Now we’re bringing tags back, but in a different form. Instead of free-form tags, we’ll provide a set of predefined tags that developers can pick from. We’re starting with a small set of tags based on what we’ve noticed users looking for, so it’s possible many add-ons don’t match any of them. We will expand the list of tags if this feature performs well.

The tags will be displayed on the listing page of the add-on. We also plan to display tagged add-ons in the AMO homepage.

Example of a tag shelf in the AMO homepage

Example of a tag shelf in the AMO homepage

We’re only just starting to roll this feature out, so we might be making some changes to it as we learn more about how it’s used. For now, add-on developers should visit the Developer Hub and set any relevant tags for their add-ons. Any tags that had been set prior to July 22, 2021 were removed when the feature was retooled.

The post New tagging feature for add-ons on AMO appeared first on Mozilla Add-ons Community Blog.