Move captive portal detection to an endpoint that returns 204
Categories
(Core :: Networking, enhancement, P3)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox155 | --- | fixed |
People
(Reporter: valentin, Assigned: valentin)
References
(Blocks 1 open bug, Regressed 1 open bug)
Details
(Whiteboard: [necko-triaged])
Attachments
(1 file)
(In reply to tim from bug 1887714 comment #15)
I tried both of those builds and both seem to work with no captive portal detection.
It seems an endpoint that responds with a 204 status would generate fewer false positives.
We should investigate how easy that is to achieve on the server-side.
| Assignee | ||
Comment 1•2 years ago
|
||
Updated•3 months ago
|
Updated•3 months ago
|
Comment 4•3 months ago
|
||
Reverted this because it was causing xpcshell failures in test_ext_captivePortal.js.
- Revert link
- Push with failures
- Failure Log
- Failure line: TEST-UNEXPECTED-FAIL | xpcshell-remote.toml:toolkit/components/extensions/test/xpcshell/test_ext_captivePortal.js | Test timed out; open profile_test_ext_captivePortal_retry.js.json in the Firefox Profiler
| Assignee | ||
Updated•3 months ago
|
Comment 6•3 months ago
|
||
| bugherder | ||
Comment 8•2 months ago
|
||
Backout as requested by dev for causing Bug 2052715 https://hg.mozilla.org/integration/autoland/rev/44adf8fbd1af
Updated•2 months ago
|
Updated•2 months ago
|
Comment 10•1 month ago
|
||
| bugherder | ||
Updated•1 month ago
|
Comment 11•1 month ago
|
||
Did you want to nominate this for the Fx155 relnotes? If so, set the relnote-firefox flag to "?"
https://wiki.mozilla.org/Release_Management/Release_Notes_Nomination
Possible wording:
Firefox now uses firefox-portal-detection.com instead of detectportal.firefox.com to detect captive portals and check network connectivity, so network allowlists referencing the old domain need updating.
| Assignee | ||
Comment 12•1 month ago
|
||
I'll nominate for relnote in bug 2049252 instead.
Updated•1 month ago
|
Updated•1 month ago
|
Description
•