Skip to content

network: wait 3 seconds for connectivity check

Previously, as soon as the network device was activated, the grey Skip button would become a blue Next button. But NM_DEVICE_STATE_ACTIVATED does not (necessarily) mean we can connect to arbitrary servers on the internet; one needs to wait for NM_CONNECTIVITY_FULL to be sure of that.

This matters because Geoclue only requests the device location once NM_CONNECTIVITY_FULL (or its GNetworkConnectivity equivalent) is reached. On Endless, the next page after the network page is the timezone page, which we skip entirely if a location can be discovered and the timezone can be automatically set. The connectivity check may not be instantaneous, so we'd rather the user not advance to the next page before it is complete. (Upstream, there's a privacy page in between, which has a toggle to enable or disable Geoclue.)

Reaching NM_CONNECTIVITY_FULL is not a guarantee that Geoclue's request to MLS has returned a location, of course; in practice, Geoclue takes about 300ms to discover its location after the connectivity check has finished on a FTTC connection in London. However, it is likely to take the user longer than 300ms to notice that the grey "Skip" button has become a blue "Next" button and click it.

If we really are behind a captive portal or on a non-internet-connected site, we don't want to make the user wait any longer once we've discovered that, so we wait for any state other than NM_CONNECTIVITY_NONE to be reached, rather than waiting for NM_CONNECTIVITY_FULL.

I originally tried switching the button from sensitive Skip to insensitive Next once the device came online, and then to sensitive Next when the check finishes. This is a stronger gate against the user moving forward too soon, but leads to the button appearing to flicker. It looks better to stick with Skip until we're ready to go.


We've shipped a version of this patch in Endless since December 12th 2018 with no reported issues. The patch did not apply cleanly here due to my own changes on !69 (merged). (Conflicting with myself! Go me!) None of the conflicts could be resolved automatically but all were reasonably straightforward.

Merge request reports