1677026 - "You must log in to this network before you can access the Internet" pops up on Windows 7 after updating Firefox 83 Beta to latest RC

Status: RESOLVED DUPLICATE of bug 1666072

(Core :: Networking, defect)

Description

[lolrepeatlol]

Attachment: MustLogIntoNetwork.PNG

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:83.0) Gecko/20100101 Firefox/83.0

Steps to reproduce:

I updated Firefox 83 Beta.

Actual results:

A banner on the top stated "You must log in to this network before you can access the Internet" even on my home network. Clicking "Open Network Login Page" directs me to https://detectportal.firefox.com/success.txt in a new tab with text that says "success." The internet works fine and browsing the web works fine.

Expected results:

I shouldn't have seen this banner pop up.

Occurs on Win 7 w/ Ethernet plugged in. When opening a new window, it still appears. I can't reproduce in a new profile. If I close the banner and close the browser, upon reopen, the banner reappears.

Comment 1

[lolrepeatlol]

Attachment: log.txt-main.11760.moz_log

Here is a log.

Comment 2

[lolrepeatlol]

I have another log file but it's fairly large at 16MB. Should I send it anyway? If so, how? I can't find a pastebin that allows that much storage, and BZ doesn't allow over 10 MB. I could divide it into two files but not sure.

Comment 3

[lolrepeatlol]

Safe Mode does not fix the issue.

Comment 4

[BugBot [:suhaib / :marco/ :calixte]]

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Comment 5

[Jan Honza Odvarko [:Honza] (always need-info? me)]

It doesn't look like the Network panel (from DevTools) is involved in the scenario. Moving to the Networking component (see also the log)

Honza

Comment 6

[Dragana Damjanovic [:dragana]]

Valentin, can you take a look?

Comment 7

[Valentin Gosu [:valentin] (he/him)]

2020-11-13 05:48:45.038000 UTC - [Parent 11760: Main Thread]: D/nsHttp nsHttpChannel::OnBeforeConnect [this=0000000013E20000 willCallback=0 rv=0]
2020-11-13 05:48:45.038000 UTC - [Parent 11760: Main Thread]: D/nsHttp nsHttpChannel::ContinueOnBeforeConnect [this=0000000013E20000 aShouldUpgrade=1 rv=0]
2020-11-13 05:48:45.039000 UTC - [Parent 11760: Main Thread]: D/nsHttp nsHttpChannel::ContinueBeginConnectWithResult result [this=0000000013E20000 rv=0 mCanceled=0]
2020-11-13 05:48:45.039000 UTC - [Parent 11760: Main Thread]: D/nsHttp nsHttpChannel::HandleAsyncRedirectChannelToHttps() [STS]
2020-11-13 05:48:45.039000 UTC - [Parent 11760: Main Thread]: D/nsHttp nsHttpChannel::StartRedirectChannelToURI()

This bug seems to be caused by automatic upgrade to HTTPS.
Christoph, it's not clear to me why this happens only in some cases.
Any ideas?

Comment 8

[Valentin Gosu [:valentin] (he/him)]

So, we set the flag here but for some reason we still upgrade. Maybe there's a bug in (NS_ShouldSecureUpgrade)[https://searchfox.org/mozilla-central/rev/c37038c592a352eda0f5e77dfb58c4929bf8bcd3/netwerk/base/nsNetUtil.cpp#2785] ?

In any case, a workaround is to set the network.captive-portal-service.enabled pref to false.

Comment 9

[Christoph Kerschbaumer [:ckerschb]]

(In reply to Valentin Gosu [:valentin] (he/him) from comment #8)

So, we set the flag here

Thanks for narrowing down the problem Valentin. It's seems the problem occurs indeed in NS_ShouldSecureUpgrade though it's not entirely certain that HTTPS-Only Mode is repsonsible for the upgrade. FWIW, we are quite cautious with HTTPS-Only upgrades and do check the pref in nsHTTPSOnlyUtils::ShouldUpgradeRequest` before performing any upgrade.

Just to state the obvious, HTTPS-Only Mode is not enabled, right?

Comment 10

[Valentin Gosu [:valentin] (he/him)]

In the end it seems it was the server that set the HSTS headers.
Fortunately there's no obvious bug in NS_ShouldSecureUpgrade.