WEB Signal 170
Firefox 155 adds tracker-block count in address bar and changes captive-portal domain
Illustration only Photo by Declan Sun on Unsplash
Firefox 155 introduces a visible tracker-block count, container reordering, stricter mailto: handling, and a new domain for captive-portal detection.
The visible tracker-block count may influence user trust and ad-blocking transparency. The captive-portal domain change requires updates to network allow lists, potentially disrupting enterprise or public WiFi setups. Web developers may need to test compatibility with stricter mailto: link behavior.
Written by elseif from the cluster below · every claim links back to a sourceThe three things worth knowing
Firefox 155 displays the number of blocked ad trackers in the address bar.
Captive-portal detection now uses a new domain, requiring network allow-list updates.
Mailto: links will only open email clients after explicit user confirmation.
THE READ
What the cluster adds up to.
Firefox 155 introduces a small but visible change for end users: a counter in the address bar showing how many ad trackers the browser has blocked. This feature makes tracking protection more transparent, which could influence user perception of privacy tools. However, the counter’s accuracy depends on the underlying blocklist, and false positives or negatives may still occur. For engineers, this change is unlikely to require immediate action but may prompt questions from users about tracker behavior.
The update also tightens security around mailto: links by requiring explicit user action before opening an email client. This prevents unintended launches of external applications, reducing potential attack surfaces. Web developers should verify that their sites handle mailto: links correctly, as users may now see additional confirmation prompts. The change aligns with broader browser trends toward stricter user consent for external actions.
A less visible but operationally significant change is the switch of the captive-portal detection domain from detectportal.firefox.com to firefox-portal-detection.com. Networks that rely on allow lists for captive-portal detection will need to update their configurations to avoid connectivity issues. This could disrupt enterprise or public WiFi setups until the new domain is whitelisted. Engineers managing such networks should prioritize this update to prevent service interruptions.
The release includes other developer-facing changes and bug fixes, though specifics are not detailed in the provided material. Web developers should test their sites against Firefox 155 to ensure compatibility, particularly if they rely on mailto: links or interact with captive-portal detection. The update does not introduce major breaking changes but may require minor adjustments in some workflows.
Written by elseif from the cluster below · checked for specifics the sources never containedTHE CLUSTER