Mozilla Addons Blog: Firefox 153 WebExtensions API updates

We had a bumper release of using publicSuffix.isKnownSuffix(), publicSuffix.getKnownSuffix(), and publicSuffix.getDomain(). This API means that extensions no longer need to bundle or maintain a suffix list to determine a hostname’s registrable domain (eTLD+1).

Both APIs were built by contributors motivated by real needs in their extensions. We take an in-depth look at these contributions, their developers, impact, and history in a forthcoming post.

documentId support across more APIs

Firefox 153 introduces documentId, a stable identifier for a document instance, including a new runtime.getDocumentId() method, several webNavigation events and methods, webRequest events, scripting injection targets, and the extension messaging APIs.

Many WebExtension APIs use tabId and frameId to identify where to perform an operation. However, because frameId identifies the frame rather than its content, the loaded document can change and the extension’s subsequent operation ends up targeting the new (intended) document. documentId addresses this problem by providing a unique ID for the document. Now, if an extension uses the ID and the frame’s document has changed, the operation fails rather than silently targeting the wrong document.

See named build-for-amo that runs the commands needed to build your extension for Firefox:

{

  "scripts": {

    "fx-build": "some commands to build your add-on for Firefox",

    "build-for-amo": "npm run fx-build"

  }

}

If you’ve a Firefox-specific build command, just point build-for-amo at it. When present, the builder invokes this script instead of guessing how to build your extension. And while you are at it, make sure all your dev dependencies are listed in the package.json file.

For more information, including documentation and Bugzilla links, see the under the WebExtensions product, cross-browser API proposals are discussed in the .

The post .