2055787 - Update documentation (esp SUMO) for new captive portal detection domain

Status: RESOLVED FIXED

(support.mozilla.org :: Knowledge Base Content, task)

Description

[Simon Friedberger [:simonf]]

https://support.mozilla.org/en-US/kb/captive-portal and https://support.mozilla.org/en-US/kb/domains-allow-firefox include detectportal.firefox.com
We are moving this to firefox-portal-detection.com so we should add that everywhere we're talking about detectportal.firefox.com. We need to keep both for a while because old Firefox versions will keep talking to the old endpoint for a long time.

Comment 1

[Kelimutu [:kiki]]

Asana link for internal reference: https://app.asana.com/1/90589597529/project/1203460865189761/task/1217020208610330?focus=true

Comment 2

[Kelimutu [:kiki]]

Assigning to Paul

Comment 3

[Paul]

Ready for review:

https://support.mozilla.org/en-US/kb/domains-allow-firefox/history

https://support.mozilla.org/en-US/kb/captive-portal/history

Comment 4

[Denys [:denyshon]]

Maybe it would be useful to add version tags, like we usually do on SUMO? What Firefox version will first use the new address?

Comment 5

[Paul]

I reached out to the requester directly about this - using both URL is not a problem in this instance.

Comment 6

[Alice Wyman]

Shouldn't we use "or" instead of "and" in the https://support.mozilla.org/en-US/kb/captive-portal article, when using both URLs?

Comment 7

[Alice Wyman]

See also https://support.mozilla.org/en-US/kb/captive-portal/revision/344903 Created: Aug 1, 2026, 2:48:28 PM (review pending)
Creator: Valentin Comment: actually, the captive portal loads are explicitly loaded over HTTP, not HTTPS

Comment 8

[Kelimutu [:kiki]]

Thanks, Paul.

I've reviewed and approved the https://support.mozilla.org/en-US/kb/domains-allow-firefox/history article.

@Alice would you like to take the review for the other one since you don't have an outstanding revision there?

Comment 9

[Alice Wyman]

(In reply to Kelimutu [:kiki] from comment #8)

Thanks, Paul.

I've reviewed and approved the https://support.mozilla.org/en-US/kb/domains-allow-firefox/history article.

@Alice would you like to take the review for the other one since you don't have an outstanding revision there?

I approved the revision by Valentin to the https://support.mozilla.org/en-US/kb/captive-portal article.

Comment 10

[Kelimutu [:kiki]]

@Alice Thanks, Alice. In the future, could you please make sure to review the oldest pending revision before approving a newer one?

It's possible that you've already reviewed the content eithout taking action on the actual revision. However, reviewing revisions in order helps ensure contributors don't feel that their work has been overlooked. It also keeps our pending revision queue accurate, so our backlog and metrics reflect work that genuinely still needs attention.

For reference, see the Reviewing multiple revisions section of the guidelines:
https://support.mozilla.org/en-US/kb/article-review-guidelines#w_reviewing-multiple-revisions

@all Thanks again for your collaboration here. I'm closing this ticket as resolved now.

Comment 11

[Alice Wyman]

(In reply to Kelimutu [:kiki] from comment #10)

@Alice Thanks, Alice. In the future, could you please make sure to review the oldest pending revision before approving a newer one?

It's possible that you've already reviewed the content eithout taking action on the actual revision. However, reviewing revisions in order helps ensure contributors don't feel that their work has been overlooked. It also keeps our pending revision queue accurate, so our backlog and metrics reflect work that genuinely still needs attention.

For reference, see the Reviewing multiple revisions section of the guidelines:
https://support.mozilla.org/en-US/kb/article-review-guidelines#w_reviewing-multiple-revisions

Kiki, Regarding https://support.mozilla.org/en-US/kb/captive-portal/history and the multiple revisions: I deferred my own pending revision, then approved the latest revision by Valentin a few days later but left the oldest pending revision by Paul "unreviewed", even though I did look at it.

You said to review the oldest pending revision before approving a newer one and referred me to the guidelines. By "review" I take that to mean, either defer or approve it. I agree, before approving the latest revision by Valentin I should have deferred Paul's revision, just like I deferred my own revision, since both had incorrect content. You are right, I should not have left it pending. The guidelines just say (quote) When there are multiple revisions pending for approval, make sure to check all of the revisions starting from the oldest one before making a decision. I think that it should be changed from "check" to "review (defer or approve)" to avoid confusion, since I did check Paul's revision but didn't take any review action.

Comment 12

[Alice Wyman]

(In reply to Denys [:denyshon] from comment #4)

Maybe it would be useful to add version tags, like we usually do on SUMO? What Firefox version will first use the new address?

According to bug 2049252 captive portal detection will move to the new domain (firefox-portal-detection.com) in Firefox version 155.

Comment 13

[Paul]

Will we still need to support the old domain for users of either of the two ESR versions?

Comment 14

[Kelimutu [:kiki]]

I'd defer that question to Simon.

@Simon can you help answer both questions from Alice and Paul? The Captive portal detection aritcle is one of the most visited articles on SUMO (if not the highest), so providing the information so we can update the article accordingly is super important for us.

Comment 15

[Simon Friedberger [:simonf]]

The old domains will still be in use by old Firefox versions and by ESRs. We should list them both in SUMO until we decide that the service running at detectportal.firefox.com has become unused and decommission it.

Comment 16

[Kelimutu [:kiki]]

Got it! I just udpated the article to make it display detectportal.firefox.com for users below 155 and firefox-portal-detection.com for users on 155 and above.