1578633 - Captive portal notification bar does not automatically go away after login

Status: VERIFIED FIXED

(Core :: Networking, defect, P1)

Description

[(inactive) Nihanth Subramanya [:nhnt11]]

I could reproduce this on a 69 release build today using the node script attached to bug 1202680.

Not sure what's going on yet, need to investigate.

Comment 1

[(inactive) Nihanth Subramanya [:nhnt11]]

Attachment: Bug 1578633 - Ensure we don't clear a portal check request until success. r=MattN

The expected behavior when a check is requested, is that CaptiveDetect.jsm
first checks for a portal, and if we are in one, it polls until we have
exited the portal. Upon success, the requester of the check should be
notified and then forgotten about. But we were forgetting about the request
as soon as we detected a portal rather than after a successful login,
which prevented us from polling. This bug was likely masked by a TypeError
for which a null-check was added in bug 1556259.

Comment 2

[Johann Hofmann [:johannh]]

[Tracking Requested - why for this release]:
Captive portal annoyance

Is there a regression range for this? Does this affect ESR 68?

Comment 3

[(inactive) Nihanth Subramanya [:nhnt11]]

Attachment: Bug 1578633 - [Captive Portal] Prevent XHR error callback if we already handled it. r=mayhemer

Comment 4

[(inactive) Nihanth Subramanya [:nhnt11]]

Yeah, regressed by bug 1556259. ESR 68 should not be affected - that patch landed in 69 and was not uplifted as far as I can tell from the bug.

Comment 5

[Johann Hofmann [:johannh]]

Thanks!

Comment 6

[(inactive) Nihanth Subramanya [:nhnt11]]

I'm improving the captive portal frontend tests in bug 1579007, to prevent this kind of regression in the future.

Comment 7

[(inactive) Nihanth Subramanya [:nhnt11]]

The improved tests in bug 1579007 fail as expected without the patch from this bug.

Comment 8

[(inactive) Nihanth Subramanya [:nhnt11]]

Comment on attachment 9090316 [details]
Bug 1578633 - [Captive Portal] Prevent XHR error callback if we already handled it. r=mayhemer

Beta/Release Uplift Approval Request

• User impact if declined: Captive Portal detection feature is left in an undesirable state after a portal is detected. The notification bar will not go away automatically after login is complete, and there MAY be broken functionality with prolonged browser use (if the user frequently uses a network with a portal and doesn't restart Firefox, for example).
• 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: Use Firefox on a network with a captive portal. Without this patch, after logging into the network, the notification bar does not go away. With the patch, it should automatically be dismissed within 3 seconds after logging in.
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): The patch ensures that a particular state is handled only once - the code change is simple and easy to test. The updated automated tests I am working on in bug 1579007 verify that this patch fixes the issue.

We should take this patch. The risk is extremely low (non-existent, even) and fixes an obvious issue, even if it turns out not to fully resolve the user-facing bug (though of course, I believe it does).

• String changes made/needed: none

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/5cde64e5062e
[Captive Portal] Prevent XHR error callback if we already handled it. r=mayhemer

Comment 10

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9090316 [details]
Bug 1578633 - [Captive Portal] Prevent XHR error callback if we already handled it. r=mayhemer

Simple fix for a new regression in 69 that's on the dot release radar. Approved for 70.0b4 so we can get as much feedback as possible before 69.0.1 gtb.

Comment 11

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-beta/rev/39405b2caefe

Comment 12

[Andreea Pavel [:apavel]]

https://hg.mozilla.org/mozilla-central/rev/5cde64e5062e

Comment 13

[Rares Doghi, Desktop QA]

Hi, Can someone help us with some steps on this issue, So far I have downloaded and started the captive-portal.js node script file from Bug 1202680 using the Command line on a Windows 10.
I have set the captivedetect.canonicalURL to hit http://localhost:8080/test in about:config and after reaching localhost:8080 in Firefox Release, Beta or Nightly I'm getting the same exact behavior on all 3:

Click Login and the Success page is displayed, but the "You must log in to this Network before you can access the internet. - Open network Login page" notification is displayed after clicking the Login button. That notification does not disappear.

I'm not sure if that is the correct notification bar that should be displayed before and after logging in but the same behavior occurs in all versions of Firefox.

Do you have any steps that might help us reproduce this issue on our end ? or maybe a different test case script ? Am I missing something here ? some steps ?

Comment 14

[(inactive) Nihanth Subramanya [:nhnt11]]

The fake captive portal script in that bug was outdated/wrong, I updated it just now. The new one should allow you to test this with the same steps you already followed. :)

Thanks!

Comment 15

[Rares Doghi, Desktop QA]

Hi, Thanks again for the help, This issue is verified as Fixed in our latest Nightly build and Beta 70.0b4 on Windows 10 , Mac oSX 10.14 and Ubuntu 18.04. I will update the flags accordingly.

Comment 16

[Henri]

Great to read about the fix here.

As a normal-ish developer-user who's not using nightlies, is there a workaround I can use to stop this appearing (in every tab I open) until firefox70 is released to the public?

Comment 17

[(inactive) Nihanth Subramanya [:nhnt11]]

(In reply to github from comment #16)

Great to read about the fix here.

As a normal-ish developer-user who's not using nightlies, is there a workaround I can use to stop this appearing (in every tab I open) until firefox70 is released to the public?

This fix is still on the radar for 69.0.1, so you might not have to wait until 70 is released.

In the meantime, if you're not interested in using nightlies or beta, you can set the network.captive-portal-service.enabled pref to false. This will suppress the notification, but it also completely disables the feature/UI. You'll need to remember to reset the pref later once this fix has made it into the release channel.

Sorry for the inconvenience!

Comment 18

[Henri]

Thanks!

Comment 20

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9090316 [details]
Bug 1578633 - [Captive Portal] Prevent XHR error callback if we already handled it. r=mayhemer

Fixes the captive portal notification bar not being dismissable in some situations. Approved for 69.0.1.

Comment 21

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-release/rev/dcea75d3a010

Comment 22

[Ryan VanderMeulen [:RyanVM]]

Added to the 69.0.1 relnotes:

Fixed the Captive Portal notification bar not being dismissable in some situations after login is complete

Comment 23

[Rares Doghi, Desktop QA]

Hi, This issue is verified as fixed in Firefox 69.0.1 on Windows 10 , Ubuntu 18.04 and Mac 10.14.

Comment 24

[jwcard]

I think there is still an issue with this feature. I am running 69.0.1 and work in a large enterprise company that uses a security service that requires us to install a certificate that allows the service so that all of our HTTPS traffic goes through that service where it can be scanned and vetted. I have no idea if this is part of the issue but thought I would mention it. We use a proxy to get out of the Intranet.

In any case, I can't seem to get rid of the "You must log in to this network before you can access the Internet."
I clicked on the "Open Network Login Page" button and get a "success" page but the banner and button do not disappear.

Comment 25

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

(In reply to jwcard from comment #24)

I think there is still an issue with this feature. I am running 69.0.1 and work in a large enterprise company that uses a security service that requires us to install a certificate that allows the service so that all of our HTTPS traffic goes through that service where it can be scanned and vetted. I have no idea if this is part of the issue but thought I would mention it. We use a proxy to get out of the Intranet.

In any case, I can't seem to get rid of the "You must log in to this network before you can access the Internet."
I clicked on the "Open Network Login Page" button and get a "success" page but the banner and button do not disappear.

I encourage you to open a new bug to investigate.
Please also attach logs, as that would make it much easier to diagnose the issue:
https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/HTTP_logging
The modules list/MOZ_LOG should be set to: sync,timestamp,nsHttp:5,CaptivePortalService:5,nsHostResolver:5

Comment 26

[jwcard]

ok, I will do that. Since I already had it in my copy/paste buffer this is one thing i noticed:

Frame 53: 295 bytes on wire (2360 bits), 295 bytes captured (2360 bits) on interface 0
Ethernet II, Src: PaloAlto_e2:80:46 (b4:0c:25:e2:80:46), Dst: LcfcHefe_b6:80:2d (8c:16:45:b6:80:2d)
Internet Protocol Version 4, Src: 165.225.38.37, Dst: 10.169.104.72
Transmission Control Protocol, Src Port: 443, Dst Port: 64955, Seq: 2989048525, Ack: 954413102, Len: 241
Hypertext Transfer Protocol
[Expert Info (Warning/Security): Unencrypted HTTP protocol detected over encrypted port, could indicate a dangerous misconfiguration.]
[Unencrypted HTTP protocol detected over encrypted port, could indicate a dangerous misconfiguration.]
[Severity level: Warning]
[Group: Security]
HTTP/1.1 407 Unauthorized\r\n
[Expert Info (Chat/Sequence): HTTP/1.1 407 Unauthorized\r\n]
Response Version: HTTP/1.1
Status Code: 407
[Status Code Description: Proxy Authentication Required]
Response Phrase: Unauthorized
Server: Zscaler proxy\r\n
Cache-control: no-cache\r\n
Content-Length: 0\r\n
Proxy-Authenticate: Digest realm="zscaler.net", qop="auth", opaque="9af8671e8efb68825c9446411d42b48a", nonce="09c29602c026ca4a182425db9d47401f"\r\n
\r\n
[HTTP response 1/1]
[Time since request: 0.011333000 seconds]
[Request in frame: 52]
[Request URI: www.zscaler.com:80]

Comment 27

[Petaris]

(In reply to jwcard from comment #24)

I think there is still an issue with this feature. I am running 69.0.1 and work in a large enterprise company that uses a security service that requires us to install a certificate that allows the service so that all of our HTTPS traffic goes through that service where it can be scanned and vetted. I have no idea if this is part of the issue but thought I would mention it. We use a proxy to get out of the Intranet.

In any case, I can't seem to get rid of the "You must log in to this network before you can access the Internet."
I clicked on the "Open Network Login Page" button and get a "success" page but the banner and button do not disappear.

I am experiencing a similar issue, again in a large enterprise. Did you end up creating a bug? If so, what is the ID number?

Comment 28

[jwcard]

No, sorry, I didn't I ended up getting side tracked and didn't capture the requested logs.

Comment 29

[jwcard]

@petaris, I did manage to create a defect: 158612

Comment 30

[jwcard]

Hmm, sorry should be 1586126

Comment 31

[Petaris]

(In reply to jwcard from comment #30)

Hmm, sorry should be 1586126

Thanks jwcard!

Comment 32

[Kev Scout]

Message persists for me too. Large corporate environment filtering traffic through zscalar. Looks like some good discussion and investigation happening on 1586126. Will follow there. I'm just an end user, not responsible for the app.

Comment 33

[BigWill]

Did this not make it into the 70.0 release? I'm still seeing this bug here. We're using integrated windows authentication (IWA) in our environment to authenticate users to our proxy. We've used it for a long time with Firefox without issue and started receiving the "You must login" banners sometime in the last two releases of Firefox. For the most part it seems to just be annoying and doesn't seem to cause any functional problems but it does result in a lot of Help Desk calls for us. In case you need it we use the below Firefox settings for configuring end-user devices for IWA authentication to our proxy.

network.automatic-ntlm-auth.trusted-uris
network.negotiate-auth.delegation-uris
network.negotiate-auth.trusted-uris
signon.autologin.proxy

Comment 34

[Henri]

Yep, I saw 70 get released and turned off my bodge-fix (setting network.captive-portal-service.enabled to false) and it's still popping up everywhere. I'm in a corporate environment where all traffic goes out via an HTTPS Proxy with a PAC file. Really poor - it's annoying my entire floor and i've had to go round applying this patch or tell them to move to Chrome as primary in the interim

Comment 35

[(inactive) Nihanth Subramanya [:nhnt11]]

Folks, thank you for your feedback on this issue - please note that the issue with enterprise environments is being tracked in bug 1586126. We've triaged it already and it will be worked on when someone is available to do so.