Status

()

For bugs in Firefox Desktop, the Mozilla Foundation's web browser. For Firefox user interface issues in menus, developer tools, bookmarks, location bar, and preferences. Many Firefox bugs will either be filed here or in the Core product. (more info)

Currently it appears that at startup, the CaptivePortalWatcher (browser-captivePortal.js) is the only consumer triggering a recheck. Per my investigation, commenting out the recheck call in that file results in no XHR ever being created from captivedetect.js long after the first window has loaded and even after some minor browsing. It seems that the calls in nsIOService when the network link changes or when the pref changes don't happen at startup. When I realized there were no other rechecks being triggered I didn't dig deeper.
Once the NSS-init-off-main-thread work is done, we should investigate for a better way to trigger the first recheck.

Comment on attachment 8873257[details]Bug 1367450 - Don't trigger captive portal check until delayed startup has completed.
https://reviewboard.mozilla.org/r/144712/#review148682
Looks good to me. I wonder if there's a way to test this. Currently captivedetect.js doesn't show up at all in the test I wrote in bug 1358798, so blacklisting it there before first paint wouldn't help. I assume captive portal detection is off for mochitests to avoid external network requests. I wonder if we could change this to instead check an url hosted by the mochitest server, so that the tests would see a behavior closer to what users experience. Is this something you can investigate?

Comment on attachment 8873257[details]Bug 1367450 - Don't trigger captive portal check until delayed startup has completed.
Sorry about the test failures, try seems green now.
CaptivePortalWatcher attempts to open the portal tab after xul-window-visible if a portal has already been detected before the window was opened. There is a test for this.
If we move CaptivePortalWatcher into delayedStartup, xul-window-visible is a thing of the past, so it waits forever to open the tab, causing the test to fail.
Rather than messing with the mechanism of the portal tab/tests, I've simply kept the CaptivePortalWatcher.init() call where it was, and instead have moved the recheck trigger to after delayed-startup within browser-captivePortal.js, which is what we really cared about anyway.

QA note: this changed the code used to start captive portal detection, so it would be good to do some exploratory testing around the captive portal feature to verify that it still works as expected and that delaying its initialization doesn't introduce notable regressions.

verified on: OSX 10.10, OSX 10.12, Ubuntu 16.04 x64, Ubuntu 14.04 x32, Windows 10x64
56.0a1 20170718100239
55.0b10 20170717064120
Run the basic Captive Portal scenarios:
-Active/Inactive CP detection;
-CP canonical redirect ;
-CP managers(OSX/Win) integration related to FF startup;
There is only one thing I've noticed: on OSX, the CP assistant is launched again after FF is started and CP detection succeeds. However, I cannot reproduce the above behavior consistently. My current assumption is that the above behavior was network related (only one available CP capable wi-fi network for testing - will follow up on this once I get the chance to try on a different CP wi-fi network), so marking this issue as verified.