2052715 - captive portal at detectportal-fastly.firefox.com/canonical.html cresponds with 200, Firefox expects 204, loops forever

Status: RESOLVED FIXED

(Core :: Networking, defect)

Description

[Rob Wu [:robwu]]

When I updated Nightly to the latest version (154.0a1 buildid 20260704213149) and restarted, I saw an infobar with the following message in all of my browser windows:

You must log in to this network before you can access the Internet.

This was strange because I was able to use the internet just fine. When I open the Browser Toolbox, I saw repeated attempts to connect to the captive portal check (an example is shared below).
After a few minutes I saw the infobar warning me about unsubmitted crashes (in one window), and at that time the captive portal infobar disappeared from all other windows that were open.

When I put a breakpoint at CaptiveDetect.sys.mjs's response handler of URLFetcher, I see that xhr.status is 200, but the value of the captivedetect.expectedStatus pref is 204, for a request to http://detectportal-fastly.firefox.com/canonical.html

The value of the captivedetect.canonicalURL preference is http://detectportal.firefox.com/canonical.html (in about:config I can see that it is boldfaced, so it is not the default value). I did not manually configure that value. Moreover, with the devtools I can see that captivePortalDetector._canonicalSiteURL is set to http://detectportal-fastly.firefox.com/canonical.html (note the "-fastly" in the subdomain). Since the preference is read once in the CaptivePortalDetector constructor and not updated after that, I guess that the preference changed in the meantime (not by me, definitely!).

I am marking this as a regression of bug 1898891, because that bug changed captivedetect.expectedStatus from 200 to 204.

Request:

GET /canonical.html HTTP/1.1
Host: detectportal-fastly.firefox.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:154.0) Gecko/20100101 Firefox/154.0
Accept: */*
Accept-Language: en-US,en;q=0.9
Accept-Encoding: gzip, deflate
Cache-Control: no-cache
Pragma: no-cache
DNT: 1
Connection: keep-alive

Response:

HTTP/1.1 200 OK
Connection: close
Content-Length: 90
Server: Varnish
Retry-After: 0
Content-Type: text/html
Accept-Ranges: bytes
Date: Sun, 05 Jul 2026 12:29:40 GMT
Via: 1.1 varnish
X-Served-By: cache-rtm-ehrd2290037-RTM
X-Cache: MISS
X-Cache-Hits: 0
X-Timer: S1783254581.726939,VS0,VE0
Cache-Control: public, must-revalidate, max-age=0, s-maxage=3600

Comment 1

[Rob Wu [:robwu]]

After a browser restart, requests are now sent to http://detectportal.firefox.com/canonical.html instead of http://detectportal-fastly.firefox.com/canonical.html , but still the status is 200 instead of 204.

The issue only resolved after manually resetting the preference to its default (http://detectportal.firefox.com/generate_204 from bug 1898891), AND after restarting the browser.

Comment 2

[BugBot [:suhaib / :marco]]

:valentin, since you are the author of the regressor, bug 1898891, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Comment 3

[Silaghi Andreea]

Regressor Bug 1898891 , was backout at dev request.
https://hg.mozilla.org/integration/autoland/rev/44adf8fbd1af

Comment 4

[Simon Friedberger [:simonf]]

Jon, is this an issue with Fastly or was bug 2038027 incomplete?

Comment 5

[Jon Buckley [:jbuck]]

It's funny, I encountered the exact same behaviour as :robwu because my Firefox Nightly also had a pref override. And I also fixed it the same way, by resetting the pref to default. So I think it's something else.

Is it possible that the experiment we ran to test Nightly's population with the Fastly implementation left the preference set to http://detectportal.firefox.com/canonical.html instead of valentin's patch setting it to http://detectportal.firefox.com/generate_204? Or is this a problem with anyone who has set the captivedetect.canonicalURL pref?

Comment 6

[:Gijs (back August 25; he/him)]

(In reply to Jon Buckley [:jbuck] from comment #5)

It's funny, I encountered the exact same behaviour as :robwu because my Firefox Nightly also had a pref override. And I also fixed it the same way, by resetting the pref to default. So I think it's something else.

Is it possible that the experiment we ran to test Nightly's population with the Fastly implementation left the preference set to http://detectportal.firefox.com/canonical.html instead of valentin's patch setting it to http://detectportal.firefox.com/generate_204? Or is this a problem with anyone who has set the captivedetect.canonicalURL pref?

--> Beth? I'm additionally confused (probably heatwave brain but still) because I don't see this experiment in about:studies but my prefs also changed.

Comment 7

[Beth Rennie [:beth] (she/her)]

It's a rollout. Rollouts do not appear in about:studies (because they're not studies). You can see the what rollouts you're enrolled in via checkout about:support (Remote Features) or setting nimbus.debug=true and reloading about:studies.

Comment 8

[Beth Rennie [:beth] (she/her)]

prefFlips should not persist after unenrollment and this rollout ended on June 24. If the pref persisted after the rollout ended and unenrollment was confirmed, that is indeed a bug in Nimbus.

Comment 9

[Rob Wu [:robwu]]

(In reply to Beth Rennie [:beth] (she/her) from comment #8)

prefFlips should not persist after unenrollment and this rollout ended on June 24. If the pref persisted after the rollout ended and unenrollment was confirmed, that is indeed a bug in Nimbus.

Unenrollment worked, in the sense that the experimental value was discarded.
But what was restored is the old default, not the new default. I filed bug 2053938 for that.

Although the experimental value was discarded, the pref did not take effect until a restart, because the captivedetect.canonicalURL pref was read once: https://searchfox.org/firefox-main/rev/609faad611b33bee94f2fcb455a6b840093bab89/toolkit/components/captivedetect/CaptiveDetect.sys.mjs#250-252

I suppose that this bug here is also directly caused by the fact that the URL is read once from a pref, whereas captivedetect.expectedStatus is read every time it is needed: https://searchfox.org/firefox-main/rev/609faad611b33bee94f2fcb455a6b840093bab89/toolkit/components/captivedetect/CaptiveDetect.sys.mjs#64 (well that code has been reverted).

Comment 10

[Rob Wu [:robwu]]

Changing WONTFIX to FIXED, by:

• bug 1898891 patch was backed out
• bug 2054546 repaired the prefs for those who were affected.