2016676 - “Use VPN for this site” cannot be enabled if the website address was added without “www” in about:preferences - “Manage website settings”

Status: VERIFIED FIXED

(Firefox :: IP Protection, defect)

Description

[Valentina Virlics [:vvalentina], VPN QA]

Attachment: Recording 2026-02-13 133621.mp4

[Affected versions]:

• Firefox Nightly 149.0a1 (2026-02-12);

[Affected Platforms]:

• Windows 11 x64;

[Prerequisites]:

• Be enrolled into the VPN experiment;
• Be logged in;
• Having the VPN in ON state.

[Steps to reproduce]:

1. Click the Settings option from the VPN main panel;
2. Click “Manage website settings”;
3. Add youtube.com to the exclusion list and “Save changes”
4. Load youtube.com in a new tab and observe the VPN status;
5. Enable “Use VPN for this site” and observe the VPN status;
6. Refresh the page and observe the VPN status;

[Expected result]:
Step 4: “Use VPN for this site” is disabled; the YT website is excluded from protection; VPN is on and has a hollow circle.
Step 5: “Use VPN for this site” is enabled; YT is protected; VPN is ON and has a solid green dot;
Step 6: YT is protected; VPN is ON and has a solid green dot;

[Actual result]:
Step 4: “Use VPN for this site” is disabled; the YT website is excluded from protection; VPN is on and has a hollow circle.
Step 5: “Use VPN for this site” is enabled; YT is protected; VPN is ON and has a hollow circle;
Step 6: “Use VPN for this site” is disabled; YT is not protected; VPN is ON and has a solid green dot;

[Notes]:
Not reproducing if the URL of the website is copy-pasted in the Manage website settings modal, hance has the “www” included.

Comment 1

[kpatenio]

Attachment: Bug 2016676 — revert exactHost=false to stop subdomains from being implicitly excluded. r=#ip-protection-reviewers!

Comment 2

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/e182c5e7a560
https://hg.mozilla.org/integration/autoland/rev/a35a8224c831
— revert exactHost=false to stop subdomains from being implicitly excluded. r=ip-protection-reviewers,fchasen

Comment 3

[kpatenio]

Hey QA team,

Just a heads up that the patch for this bug essentially undoes the original fix for Bug 2012113. We initially relaxed the restrictions for checking site exclusions to work like this:

• Inputting apple.com in the dialog --> excludes www.apple.com and www.developer.apple.com

But now, we reverted the change so that we're strict about site exlcusions for domains without www:

• Inputting apple.com in the dialog --> does _not _ exclude www.apple.com or www.developer.apple.com
• This means we need to be specific with our URLs in the dialog to use www

This is to ensure we avoid hitting this visual bug with the exclusion state UI on the panel. Once the patch lands, could you please verify the issue on Windows 11?

Comment 4

[amarc]

https://hg.mozilla.org/mozilla-central/rev/a35a8224c831

Comment 5

[Valentina Virlics [:vvalentina], VPN QA]

Verified this on Firefox Nightly 149.0a1 (22-02-2026) using Windows 11. While adding wikipedia.org (without www) in about:prefrences the www.wikipedia.org is not excluded and while adding www.mullvad.net (with www) in about:preferences the mullvad.net is not excluded. Is this the intended change/revert?
Also this bug is not reproducing anymore.

Comment 6

[kpatenio]

(In reply to Valentina Virlics [:vvalentina], VPN QA from comment #5)

Verified this on Firefox Nightly 149.0a1 (22-02-2026) using Windows 11. While adding wikipedia.org (without www) in about:prefrences the www.wikipedia.org is not excluded and while adding www.mullvad.net (with www) in about:preferences the mullvad.net is not excluded. Is this the intended change/revert?
Also this bug is not reproducing anymore.

Hi Valentina,

That's correct, this is the intended change. Unfortunately, due to the way we identify exclusions via the Permissions system, there were some challenges dealing with sites without www. A URL without www may cause more than one site to be labelled as exclusions (eg. see my apple.com vs developer.apple.com example in this comment), which could lead to unintended behaviour.

To avoid this bug from happening in the first place, I reverted the changes from Bug 2012113.