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

Steps to reproduce:

After a very short temporary loss of Internet due to a power failure, Firefox has detected that Internet was not available.
However, it never recovers from this status. It permanently keeps showing the extra Menu bar "You must log in to this network before you can access the Internet." This keeps showing up on all new windows and tabs. When clicking on the "Open Network Login Page" button, an empty window shows with the word "Success".
Nothing changes.

The only way to fix the problem is a full close of ALL Firefox windows, and a full restart.
This problem has been here for as long as I can remember.

Bart Kindt
Developer, SARTrack Limited
https://www.sartrack.nz
New Zealand

Actual results:

As above

Expected results:

It should clear itself automatically after it detects the Internet is back online, and especially after clicking on the "Open Network Login Page" button, which reports a "Success"

Bart

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

Thanks for the report.
Can you reproduce the bug on demand, or is it intermittent?
By "is fixed by a full restart" do you mean of Firefox, or of the operating system?

When you hit the bug again, could you gather some HTTP logs for us?
https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/HTTP_logging
And in the modules also add CaptivePortalService:5 (separated by comma)

Thanks!

This is what I get every time I open a new Firefox window, before I click on the button.
Internet is back for days, it does not clear itself.

This is after clicking the button.
It does not make any difference. It does not clear the State Firefox is in.

Hi,

I can probably reproduce on demand. However, since I reported the bug some days ago, I have not restarted Firefox, and the bug problem is still present right now: When I open a new Firefox window or tab, I still get this warning on the top of the window. Ever after having perfectly good Internet for the last few days.
I have now attached screenshots. This is several days after we had a short Internet outage.

Note that Firefox works normally, there are no Internet related issues. It simply does not clear the State 'Oh, there is no Internet' after this has happened once.
Restarting Firefox fixes the problem.

I am not familiar with "add CaptivePortalService:5 on the modules", I am not a Firefox developer, I am a Deplhi Pascal developer :)

Bart.

So basically, expected behaviour should be:

1. Firefox should automatically dectect thet the Internet is again available, and stop adding this warning.
2. Firefox should CLEAR this warning after the button is pushed, and getting a "success", it should then remove the warning from the (open) Window, and it should STOP adding the warning to any new Windows or tabs.

Bart

(In reply to Valentin Gosu [:valentin] (he/him) from comment #2)
Please see this link:

https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/HTTP_logging

It has step by step instructions on how to capture the logs.
After that please zip them and attach them here or email them to me.

Hello,

I've got the same message (in french) since about 1 hour ago (the computer just woke from suspend). I don't have any connection problem (and it's only on one device in my network). The message appears at each start of the browser.

I attach the logs requested above.

Firefox 82.0.3 on linux 64bits
Mozilla/5.0 (X11; Linux x86_64; rv:82.0) Gecko/20100101 Firefox/82.0

I can confirm this bug with Firefox 82.0.3 (64-Bit) on Windows 10 x64 (latest updates installed), log is attached. I don't have any proxy or login barrier, yet FF keeps telling me I must login before I can access the internet. Browsing works without issues though.

FWIW, I just cleared my cache/site date/cookies and the message didn't reappear at the next restart of the browser.

This is caused by the HSTS header sent from firefox.com (the header includes subdomains), which is causing us to upgrade requests to the captive portal detection service. The captive portal service is designed to run on http: only (captive portals will block TLS requests or substitute their own certificate, breaking the request), which is why this breaks.

[Tracking Requested - why for this release]:
Notification bars for everyone who visits firefox.com is not nice.

It would be best to ship both a fix to the captive portal fix, so prevent us trying to do any HSTS fixes, and a fix to the server code.

I have a one-liner fix ready for manual testing.
Currently writing automated tests.

https://firefox.com/ sends strict-transport-security: max-age=31536000; includeSubDomains
and http://firefox.com sends the upgrade-insecure-requests: 1 header.

Combined, these cause the captive portal check to report a redirect, which
triggers the locked captive portal banner. The fix is to exclude the captive
portal channel from the upgrade.

Comment on attachment 9188024 [details]
Bug 1666072 - Disable HSTS upgrade for captive portal channels r=Gijs

Beta/Release Uplift Approval Request

• User impact if declined: Users who have visited firefox.com after we set the HSTS header will be presented with an annoying "Log in to captive portal" banner that keeps coming back.
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: Visit firefox.com
  Restart browser
  Check if firefox.com:HSTS is in SiteSecurityServiceState.txt
  See if captive portal banner shows up
• List of other uplifts needed: None
• Risk to taking this patch: Medium
• Why is the change risky/not risky? (and alternatives if risky): This is a relatively simple change and the captive portal code has some test coverage.
  This likely needs manual testing too to make sure it doesn't break something in exciting new ways.
• String changes made/needed:

I pushed to try with the beta branch to have quick builds for QA.
https://treeherder.mozilla.org/jobs?repo=try&revision=ed7cd766a061868b980da91c53fb21d1eafcc24d

Backed out for causing xpcshell failures.

Backout link: https://hg.mozilla.org/integration/autoland/rev/f3f800928642224aadf4c939249a81b7ec789d1e

Push with failures: https://treeherder.mozilla.org/jobs?repo=autoland&selectedTaskRun=Yc6RTUHAThuwv6qfcIW2SQ.0&resultStatus=testfailed%2Cbusted%2Cexception&revision=17ecebdc6d8b5b4b8fb4e20392f6380928207a14

Failure log: https://treeherder.mozilla.org/logviewer?job_id=321907073&repo=autoland&lineNumber=4218

"INFO - TEST-PASS | netwerk/test/unit/test_trr.js | test25d - [test25d : 144] Checking result for domain.other - "127.0.0.1" == "127.0.0.1"
[task 2020-11-16T14:16:36.551Z] 14:16:36 INFO - (xpcshell/head.js) | test run_next_test 43 pending (2)
[task 2020-11-16T14:16:36.551Z] 14:16:36 INFO - (xpcshell/head.js) | test test25d finished (2)
[task 2020-11-16T14:16:36.552Z] 14:16:36 INFO - netwerk/test/unit/test_trr.js | Starting test25e
[task 2020-11-16T14:16:36.553Z] 14:16:36 INFO - (xpcshell/head.js) | test test25e pending (2)
[task 2020-11-16T14:16:36.553Z] 14:16:36 INFO - (xpcshell/head.js) | test run_next_test 43 finished (2)
[task 2020-11-16T14:16:36.553Z] 14:16:36 INFO - PID 18572 | FATAL ERROR: Non-local network connections are disabled and a connection attempt to detectportal.firefox.com (192.192.192.192) was made.
[task 2020-11-16T14:16:36.554Z] 14:16:36 INFO - PID 18572 | You should only access hostnames available via the test networking proxy (if running mochitests) or from a test-specific httpd.js server (if running xpcshell tests). Browser services should be disabled or redirected to a local server.
[task 2020-11-16T14:16:36.554Z] 14:16:36 INFO - PID 18572 | AddressSanitizer:DEADLYSIGNAL
[task 2020-11-16T14:16:36.555Z] 14:16:36 INFO - PID 18572 | =================================================================
[task 2020-11-16T14:16:36.555Z] 14:16:36 ERROR - PID 18572 | ==18572==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000001 (pc 0x7f28555b5b4b bp 0x7f28417cae30 sp 0x7f28417ca5e0 T4)
[task 2020-11-16T14:16:36.555Z] 14:16:36 INFO - PID 18572 | ==18572==The signal is caused by a WRITE memory access.
[task 2020-11-16T14:16:36.556Z] 14:16:36 INFO - PID 18572 | ==18572==Hint: address points to the zero page.
[task 2020-11-16T14:16:36.556Z] 14:16:36 INFO - PID 18572 | error: address range table at offset 0x5780 has an invalid tuple (length = 0) at offset 0x5790
[task 2020-11-16T14:16:36.557Z] 14:16:36 INFO - PID 18572 | #0 0x7f28555b5b4b in mozilla::net::nsSocketTransport::InitiateSocket() /builds/worker/checkouts/gecko/netwerk/base/nsSocketTransport2.cpp:1331:7
[task 2020-11-16T14:16:36.557Z] 14:16:36 INFO - PID 18572 | #1 0x7f28555b99ec in mozilla::net::nsSocketTransport::OnSocketEvent(unsigned int, nsresult, nsISupports*) /builds/worker/checkouts/gecko/netwerk/base/nsSocketTransport2.cpp:2219:22
[task 2020-11-16T14:16:36.558Z] 14:16:36 INFO - PID 18572 | #2 0x7f2855603cea in mozilla::net::nsSocketEvent::Run() /builds/worker/checkouts/gecko/netwerk/base/nsSocketTransport2.cpp:93:17
[task 2020-11-16T14:16:36.558Z] 14:16:36 INFO - PID 18572 | #3 0x7f2855273f77 in nsThread::ProcessNextEvent(bool, bool*) /builds/worker/checkouts/gecko/xpcom/threads/nsThread.cpp:1197:14
[task 2020-11-16T14:16:36.558Z] 14:16:36 INFO - PID 18572 | #4 0x7f285527eb0c in NS_ProcessNextEvent(nsIThread*, bool) /builds/worker/checkouts/gecko/xpcom/threads/nsThreadUtils.cpp:513:10
[task 2020-11-16T14:16:36.559Z] 14:16:36 INFO - PID 18572 | #5 0x7f28555cd2c0 in mozilla::net::nsSocketTransportService::Run() /builds/worker/checkouts/gecko/netwerk/base/nsSocketTransportService2.cpp:1195:11
[task 2020-11-16T14:16:36.559Z] 14:16:36 INFO - PID 18572 | #6 0x7f28555cf28c in non-virtual thunk to mozilla::net::nsSocketTransportService::Run() /builds/worker/checkouts/gecko/netwerk/base/nsSocketTransportService2.cpp
[task 2020-11-16T14:16:36.559Z] 14:16:36 INFO - PID 18572 | #7 0x7f2855273f77 in nsThread::ProcessNextEvent(bool, bool*) /builds/worker/checkouts/gecko/xpcom/threads/nsThread.cpp:1197:14
[task 2020-11-16T14:16:36.561Z] 14:16:36 INFO - PID 18572 | #8 0x7f285527eb0c in NS_ProcessNextEvent(nsIThread*, bool) /builds/worker/checkouts/gecko/xpcom/threads/nsThreadUtils.cpp:513:10
[task 2020-11-16T14:16:36.561Z] 14:16:36 INFO - PID 18572 | #9 0x7f2856420008 in mozilla::ipc::MessagePumpForNonMainThreads::Run(base::MessagePump::Delegate*) /builds/worker/checkouts/gecko/ipc/glue/MessagePump.cpp:302:20
[task 2020-11-16T14:16:36.561Z] 14:16:36 INFO - PID 18572 | #10 0x7f285633fb91 in RunInternal /builds/worker/checkouts/gecko/ipc/chromium/src/base/message_loop.cc:334:10
[task 2020-11-16T14:16:36.561Z] 14:16:36 INFO - PID 18572 | #11 0x7f285633fb91 in RunHandler /builds/worker/checkouts/gecko/ipc/chromium/src/base/message_loop.cc:327:3
[task 2020-11-16T14:16:36.561Z] 14:16:36 INFO - PID 18572 | #12 0x7f285633fb91 in MessageLoop::Run() /builds/worker/checkouts/gecko/ipc/chromium/src/base/message_loop.cc:309:3
[task 2020-11-16T14:16:36.562Z] 14:16:36 INFO - PID 18572 | #13 0x7f285526d074 in nsThread::ThreadFunc(void*) /builds/worker/checkouts/gecko/xpcom/threads/nsThread.cpp:442:10
[task 2020-11-16T14:16:36.562Z] 14:16:36 INFO - PID 18572 | #14 0x7f2868f77dce in _pt_root /builds/worker/checkouts/gecko/nsprpub/pr/src/pthreads/ptthread.c:201:5
[task 2020-11-16T14:16:36.562Z] 14:16:36 INFO - PID 18572 | #15 0x7f2868b816da in start_thread /build/glibc-2ORdQG/glibc-2.27/nptl/pthread_create.c:463
[task 2020-11-16T14:16:36.563Z] 14:16:36 INFO - PID 18572 | #16 0x7f284f272a3e in clone /build/glibc-2ORdQG/glibc-2.27/misc/../sysdeps/unix/sysv/linux/x86_64/clone.S:95
[task 2020-11-16T14:16:36.563Z] 14:16:36 INFO - PID 18572 | AddressSanitizer can not provide additional info.
[task 2020-11-16T14:16:36.563Z] 14:16:36 INFO - PID 18572 | SUMMARY: AddressSanitizer: SEGV /builds/worker/checkouts/gecko/netwerk/base/nsSocketTransport2.cpp:1331:7 in mozilla::net::nsSocketTransport::InitiateSocket()"

The server fix has been deployed, so the bug can't be reproduced with a new profile.
In order to reproduce, shut down Firefox, go to the profile folder, and add

firefox.com:HSTS	2	18582	1636734541693,1,1,2

to SiteSecurityServiceState.txt

Start Firefox.
You should see the captive portal banner right away (in the build without the patch)
In the build with the patch, the captive portal banner should not appear.

The test expects the only code that would call SetAllowSTS=false is the OCSP code. Making the captive portal do that too messes up expectations. A follow-up to bug 1556194 is necessary.

Depends on D97152

Hello,

I can reproduce this issue on FX. 82.0.3. I can confirm that this issue is fixed in the latest nightly (BuildID: 20201116134131). While I verified this, a fix was deployed on the server, and with help from @valentin, on the profile from 82.0.3 that had the issue, it is no longer reproducible after visiting http://firefox.com/ and https://firefox.com/ .

Given that we're likely to be landing an in-tree patch for affected releases, let's leave the status flags set to affected for now until that lands.

Comment on attachment 9188024 [details]
Bug 1666072 - Disable HSTS upgrade for captive portal channels r=Gijs

Approved for 84.0b1.

https://hg.mozilla.org/releases/mozilla-beta/rev/315c84c0ffca
https://hg.mozilla.org/releases/mozilla-beta/rev/0b60e1c7330a

Verified on 84.b01.

https://hg.mozilla.org/mozilla-central/rev/cfb55e9e43d4
https://hg.mozilla.org/mozilla-central/rev/44567f4bd356

Hello,
Verified on Firefox 85.0a1.

Verified on Firefox esr 78.5.0.

On Firefox RC 83.0 the menu bar is still visible, but after 10 seconds on firefox.com the bar disappears. Seeing as this is fixed on the server side and a dot release with this issue as a driver is not planned, I will be marking this as verified.

Comment on attachment 9188024 [details]
Bug 1666072 - Disable HSTS upgrade for captive portal channels r=Gijs

approved for 78.6esr

https://hg.mozilla.org/releases/mozilla-esr78/rev/eda9c77d3a54
https://hg.mozilla.org/releases/mozilla-esr78/rev/018983b97fb6

This bug still seems to exist in the latest ESR (91.4), if I suspend my laptop and move to a different network before resuming.

(I'm not sure if it also happens in other situations, but this is what I encounter)

(In reply to Wouter Verhelst :wouter from comment #36)

This bug still seems to exist in the latest ESR (91.4), if I suspend my laptop and move to a different network before resuming.

(I'm not sure if it also happens in other situations, but this is what I encounter)

Please could you file a new bug with more details? At this point, tracking it correctly (and evaluating where it is/isn't fixed) will be a lot easier with a new bug than if we reopen this much older, long-marked-fixed, bug.

Done, #1747057