Firefox 153 ships the new publicSuffix WebExtensions API. This API lets extensions ask the browser for the registrable domain (eTLD+1) of a hostname. It uses the browser’s built-in, always-up-to-date copy of the Public Suffix List, removing the need for extensions to bundle and maintain a copy of the list.
This feature was one of the most-voted bugs in WebExtensions on Bugzilla, and would not have been possible without the contributions by Francis McKenzie (aka mckenfra). So, thank you, Francis!
What the API does and why it exists
A “public suffix” is a domain suffix under which people can register their website names, such as .com, .co.uk, and github.io. Knowing where the public suffix ends and the registrable domain begins matters for any task that groups or isolates sites. Or any task involving the need to determine whether a given input is a likely domain, such as the autocompletion feature in the address bar that doubles as a search box.
Before this API, extensions that needed it had to bundle a copy of the Public Suffix List and update the extension whenever the list changed. As these changes happen frequently, the bundled lists were often out of sync with the browser’s interpretation.
The Firefox Multi-Account Containers extension has a longstanding request to configure containers for all subdomains. This feature would let people assign an entire domain, such as *.example.com, to a container instead of adding every subdomain by hand. Francis implemented this feature in a patch to the Multi-Account Container extension, building on top of the publicSuffix API in Firefox 153.
Behind the scenes
The first Firefox patch for this API went up in June 2022, but it wasn’t the one that shipped. That month, the bug was referred to the WebExtensions Community Group for cross-browser design, which would benefit extension developers beyond Firefox. After reaching consensus on the capability request in March 2024, Francis submitted a detailed proposal for the publicSuffix API in accordance with the WECG proposal process.
What followed was nearly a year of review. Francis made a strong case for the API having a synchronous shape, unlike almost every other extension API. Browser vendors and the Public Suffix List maintainers chimed in to leave feedback. The proposal changed shape several times in response. Approval came from Safari and Firefox in May 2025, with Chrome still tentative. Final Chrome sign-off landed in April 2026 after review at a WECG face-to-face meetup in London, and the proposal was merged. Francis then submitted the Firefox implementation patches, which landed in June and shipped in July with Firefox 153 (see changes for add-on developers in Firefox 153)!
On the WECG
None of this happened in a Mozilla-only queue. The WebExtensions Community Group exists so that an API like this doesn’t end up as three incompatible browser-specific versions. If you’ve ever hit a wall building an extension because some capability isn’t available, filing an issue at w3c/webextensions and participating in discussions is the way to make it visible to the people who can help make it happen.
As the publicSuffix API’s WECG issue shows, the process is open, with browser engineers, extension developers, and other subject matter experts (such as the Public Suffix List maintainers) discussing the API shape in public. When Firefox’s implementation was nearing completion, another Chromium contributor began an independent Chrome implementation, which revealed a possible improvement to the API. This insight resulted in a minor modification, which was approved within days. This shows the strength of multiple independent implementations collaborating on a common API.
As always, you can file extension-related issues on Bugzilla under the WebExtensions product, and cross-browser API proposals are discussed in the W3C WebExtensions Community Group. For questions, the Add-ons Discourse is the best place to start.
No comments yet
Post a comment