See https://code.google.com/p/chromium/codesearch#chromium/src/chromeos/network/shill_property_handler.cc&l=217 and https://code.google.com/p/chromium/codesearch#chromium/src/chrome/browser/chromeos/login/wizard_controller.cc&rcl=1462288634&l=822 for how this should not require a reboot for portal detection to be re-enabled.

battre@ - Any idea why EULA agreement would be needed prior to captive portal detection? I can't think of a reason why it would.

+sumit might remember the history of this.

oops. didn't mean to drop pstew@ from the thread.

<sigh> editing bugs is hard

> chrome/browser/chromeos/login/wizard_controller.cc

This code isn't actually running in my setup; I added log prints on both sides and nothing came out.

And now that I come to think of it, I'm not being asked to click through the EULA either.  Maybe one of these factors is to blame:

1) I'm running locally built test images (so they're Chromium, not Chrome)

2) I'm constantly transitioning between enterprise-enrolled + normal configurations by running `crossystem clear_tpm_owner_request=1 && reboot`

3) I'm hitting ESC to skip the update check, because Omaha times out on test images

I don't think it's (3) because nothing changed when I didn't skip the step.

I don't think it's (2) because nothing changed after a powerwash.  I probably should have reflashed via recovery to be sure, but didn't feel like spending the time yet.

So maybe skipping the EULA is WAI for (1), and that has surprising side effects on portal detection?

Assuming the actual "production" flow works correctly, wouldn't just "touch /home/chronos/.oobe_completed" fix your test workflow?

Now that we know what the problem is, merely rebooting would fix my test workflow.

So I guess the question is whether there's a good justification to leave this booby trap in the code?  This seems like something that's likely to pop up again the next time somebody tries to bisect or debug a problem with captive portal detection.

If we can't change the script, maybe Chrome should set up the CheckPortalList when it triggers the initial update check.

+ctanaka

I don't know whether there is a legal reason to have EULA consent before portal detection.

One question: Are we talking about portal detection or also about the user interacting with the portal? In the latter case there may be a risk that the user browses the web without EULA consent.

If we allow captive portal detection without EULA consent, will the user still be prompted for EULA consent next time they launch the browser? Or would this permanently bypass EULA consent for all users who happen to go through first run on a captive portal?

This captive portal detection happens at the shill layer so it should not affect the EULA UI flow.

Issue has not been modified or commented on in the last 365 days, please re-open or file a new bug if this is still an issue.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot