Closed Bug 1578633 Opened 3 months ago Closed 3 months ago

Captive portal notification bar does not automatically go away after login

Categories

(Core :: Networking, defect, P1)

defect

Tracking

()

VERIFIED FIXED
mozilla71
Tracking Status
relnote-firefox --- 69+
firefox-esr60 --- unaffected
firefox-esr68 --- unaffected
firefox69 + verified
firefox70 + verified
firefox71 + verified

People

(Reporter: nhnt11, Assigned: nhnt11)

References

(Blocks 1 open bug, Regression)

Details

(Keywords: regression)

Attachments

(1 file, 1 obsolete file)

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.

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.

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

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

Assignee: nobody → nhnt11
Status: NEW → ASSIGNED
Flags: needinfo?(nhnt11)
Priority: -- → P1
Attachment #9090297 - Attachment is obsolete: true

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.

Flags: needinfo?(nhnt11)
Regressed by: 1556259

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

See Also: → 1579007

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

Component: General → Networking
Product: Firefox → Core

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
Attachment #9090316 - Flags: approval-mozilla-release?
Attachment #9090316 - Flags: approval-mozilla-beta?
Flags: qe-verify+
Pushed by nhnt11@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/5cde64e5062e
[Captive Portal] Prevent XHR error callback if we already handled it. r=mayhemer

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.

Attachment #9090316 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Status: ASSIGNED → RESOLVED
Closed: 3 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla71
QA Whiteboard: [qa-triaged]

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 ?

Flags: needinfo?(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!

Flags: needinfo?(nhnt11)

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.

QA Whiteboard: [qa-triaged]
Flags: qe-verify+

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?

(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!

Thanks!

Duplicate of this bug: 1579991

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.

Attachment #9090316 - Flags: approval-mozilla-release? → approval-mozilla-release+

Added to the 69.0.1 relnotes:

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

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

Status: RESOLVED → VERIFIED

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.

(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

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]

(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?

Flags: needinfo?(jwcard)

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

Flags: needinfo?(jwcard)

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

Hmm, sorry should be 1586126

(In reply to jwcard from comment #30)

Hmm, sorry should be 1586126

Thanks jwcard!

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.

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

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

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.

You need to log in before you can comment on or make changes to this bug.