Closed Bug 1289686 Opened 5 years ago Closed 3 years ago

Captive portal detection doesn't trigger


(Core :: Networking, defect, P2)






(Reporter: mt, Assigned: valentin)


(Blocks 1 open bug)


(Whiteboard: [necko-next])

The network at the Sheraton Stockholm drops connectivity mid-session.  It then re-inserts the captive portal, which causes a whole bunch of things to break (usually with certificate errors).  Some folks here are getting the new tab with the captive portal, but I am not.
I suspect a link change event is causing the other folks to actively probe the CP - where you for whatever reason are not experiencing a link change event.

cheking rates differ based on whether or not your session has ever noticed the portal, etc..

valentin may be interested in your data for tuning.
Flags: needinfo?(valentin.gosu)
Yes, the local link state didn't change, but something elsewhere on the network did.
Timing is indeed a problem and I'm not sure if we can fix it for good.
So, lets say the timer is set for 60 seconds. If you keep navigating, and get a redirect to, we don't count that as a hint we're in a captive portal, so it has to wait 60 seconds or more. If you do get a cert error, that should trigger the CP detection, but it will take several more seconds until it confirms we're in a portal.
Assignee: nobody → valentin.gosu
Flags: needinfo?(valentin.gosu)
Whiteboard: [necko-next]
I think mt is saying that the tab did not appear - even after a reasonable time of having observed the cert err
Bulk change to priority:
Priority: -- → P2
I haven't seen this on any captive portal, so I'm closing this as WORKSFORME.
Please reopen if you find it's reproducible on any network. Logging [1] with the following modules would be useful: timestamp,sync,nsHttp:5,CaptivePortalService:5,nsHostResolver:5

Closed: 3 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.