I'm not sure I followed all of that, it sounds like there may be an edge case there.

The intended behavior is that Chrome calls RequestBestConnection after (a) policies have been applied, and (b) a scan has been completed. We also call RequestBestConnection after ClientCertResolver::ResolveNetworks() completes so that after a certificate is installed we then auto connect to the now available network.

It is certainly possible that ClientCertResolver::ConfigureCertificates() is too aggressive about calling ResolveRequestCompleted(). Fixing that sounds reasonable to me, as long as we ensure and test that ResolveRequestCompleted gets called after a successful certificate installation.

Note specifically: "User logged in" and "Policy applied" are not sufficient for the case of installing a certificate after login. (i.e. the first time a user logs into a new device, they will need to install a certificate; attempting to connect to Google-A will prompt a notification that will lead to the certificate being installed, at which point the auto connect to Google-A should occur).

I suspect that the desired behavior might be: when the match is first made (either because a cert appeared, or Google-A showed up in the scan results after scan(s) in which it didn't) we want to call RequestBestConnection().  But if this has happened before, and then the user has chosen to connect to another network while Google-A was in range, we don't want to drop that connection and force a connection to Google-A.

So if the cert resolver checks to see if the shill properties have been populated, and only marks network_properties_changed_ = true if the new values are different from the old values, will that work?

(Not sure how much of this stuff is currently cached in Chrome, though.)

So, there is a use case where:

1. User logs in to a device with no cert or an expired cert.
2. User explicitly connects to e.g. GoogleGuest.
3. User installs a cert.
4. User should be auto connected to e.g. Google-A.

Also, 2 and 3 could be inverted if the user requested a cert before connecting to a network, or switched networks because, e.g. GoogleGuest is slow. So we can't necessarily use "the user manually connected to a network" as an indicator that they do not want to switch.

The assumption at the moment is: If a user installs a cert that may allow them to connect to a more secure network, we should do so.

So, if we are incorrectly calling RequestBestConnection when no cert has been installed, then it makes sense to fix that.

If we are *uncertain* whether a cert installation should trigger a new connection, the preference to date was to error on the side of switching to the new connection.

AutoConnectHandler was written to put as much of that code in one place as possible, so hopefully it won't be too tricky to figure out the right fix. Feel free to add NET_LOG entries if needed.