ni? Fallen to consider and fit in somewhere.

Thanks for tagging me. I'm fine with having this sort of API available, though I'm not sure about the approach. If we are going to be exposing this on the window I'd prefer if we could work towards standardizing it instead of having a WebExtensions specific window property.

BTW: there are also Rust implementations in an attempt to parse PSL quickly:
https://crates.io/crates/psl

There are hundreds of JS libraries and all big extensions like Adblock Plus parse the PSL multiple times on each link on a every website. However, these are all not very efficient.

I use a Regex in my scripts that is executed on every website link. This Regex checks if a link is a referrer link (e.g. http://www.yahoo.de/redirect.cgi?=www.standard.co.uk). For different conditions, the PSL has to be parsed 4 times on each link on a website.
Adbuster's reference implementation is using an array map which results in an overall performance loss of 20% for each website, but it would be awesome if there would be a faster, FF integrated solution.

I filed an issue to discuss this feature in the WebExtensions Community group:

https://github.com/w3c/webextensions/issues/231
("Extension API to find the public suffix (eTLD) of a given URL/domain")

Exposes a call to Services.eTLD.getPublicSuffix(url) as a new
webextensions API method: browser.dns.getPublicSuffix(url)

E.g. getPublicSuffix("https://www.mozilla.co.uk:80") => "co.uk"

The method also takes an optional "additionalParts" integer parameter:

E.g. getPublicSuffix("https://www.mozilla.co.uk:80", 1) => "mozilla.co.uk"

This will save Addon creators from having to reinvent the wheel.
The Mozilla Multi-Account Containers Addon team intends to use this functionality
for a Wildcard Subdomains feature that is currently in development, see PR:
https://github.com/mozilla/multi-account-containers/pull/2352

The severity field for this bug is relatively low, S3. However, the bug has 277 votes and 5 See Also bugs.
:3ecdbelo, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

The bug assignee is inactive on Bugzilla, so the assignee is being reset.

:mcfrenka

After some discussions in the WECG there is a generally positive sentiment towards a (cross-browser) extension API for public suffix. Are you interested in creating a proposal in the WECG so that we can finalize the details of the API? Once that is done the patch can be tweaked based on the feedback and landed.

The proposal process is described at https://github.com/w3c/webextensions/blob/main/proposals/proposal_process.md

I mentioned this status at https://github.com/w3c/webextensions/issues/231#issuecomment-2247438680

:robwu

Thanks for pushing this forward. Yes I would be interested in creating a WECG proposal. What sort of timeframe would be good (for creating the proposal)?

There is no time pressure here. It is totally fine if you need a few weeks to find time. Feel free to contact me on Matrix if you have some quick questions.

The bug assignee is inactive on Bugzilla, so the assignee is being reset.

Clear a needinfo that is pending on an inactive user.

Inactive users most likely will not respond; if the missing information is essential and cannot be collected another way, the bug maybe should be closed as INCOMPLETE.

For more information, please visit BugBot documentation.

Depends on D295511

Depends on D295512

Depends on D295513

Depends on D295513

https://hg.mozilla.org/mozilla-central/rev/d7930fce5f5f
https://hg.mozilla.org/mozilla-central/rev/cbaac863416c
https://hg.mozilla.org/mozilla-central/rev/3acb0ec288ca
https://hg.mozilla.org/mozilla-central/rev/19d514f906a1

Thanks a lot Francis for your contribution here. This marks the completion of one of the most voted on bugs in WebExtensions on Bugzilla!

:mckenfra contributed the following significant pieces:

• Public Suffix API proposal document: https://github.com/w3c/webextensions/blob/main/proposals/public-suffix.md
• Public Suffix API in Firefox (patches above).

Through the effort he showed a lot of patience, since it took over a year between the start of the proposal and the final approvals. But the cross-browser alignment and community efforts paid off, because we now have a cross-browser publicSuffix extension API implementation, including a late fixup to the API (part 4 patch of the patch stack, renaming "unicode" to "display") following cross-browser implementer experience that highlighted an issue (https://github.com/w3c/webextensions/pull/1013).

Documentation updates in:

• (BCD) Bug 1315558 webExtensions Public Suffix API #29822
• (content) Bug 1315558 documentation for the publicSuffix API #44401

For those interested, I created a blog post with an overview of how the publicSuffix API was developed, at https://blog.mozilla.org/addons/2026/08/06/how-the-publicsuffix-api-was-created/

I'm working on the Chromium implementation of this API at the moment, and I noticed a (very minor) bug in the Firefox implementation. For a case like browser.publicSuffix.isKnownSuffix("invalid%.domain"), the API is returning false instead of throwing an exception. That seems to contradict the API proposal and the docs in MDN (and soon to be the Chromium implementation).

By the way, I noticed a few edge-cases that Chromium's hostname normalisation logic handled possibly more permissively than spec'd for this API:

• "subdomain%2edomain.com" -> Considered valid (normalised to "subdomain.domain.com")
• "foo_bar.com" -> considered valid
• "domain。com" -> Considered valid (normalised to "domain.com")

I tested those cases against the implementation here, and found Firefox agreed except the "subdomain%2edomain.com" case. So I have proposed we also reject the "subdomain%2edomain.com" case in Chromium.