jonathanhatting@ Thanks for the issue.

Able to reproduce the issue on Windows 10, Mac OS 10.13.3 and Ubuntu 14.04 on the latest Canary 68.0.3433.0 and Beta 67.0.3396.48 by the steps mentioned in the original comment.

On executing the given code in Console, can observe that there is a delay in displaying the output.
Attached is the screen cast for reference.

This is a Non-Regression issue as this behavior is observed from M60 Chrome builds. 
Hence marking this as Untriaged for further updates from Dev.

Thanks..

Deleted: 844061.mp4 1.2 MB

	844061.mp4 1.2 MB View Download

The delay is caused by a poor interaction between NetworkLocationProvider and WifiDataProvider that adds a delay of ~2 seconds when returning a cached position estimate. When the network geolocation service is used correctly, NetworkLocationProvider should return an estimate in under a second.

Short answer: The workaround is to use geolocation.watchPosition when you need up-to-date geolocation estimates. This avoids the issues with polling geolocation.getCurrentPosition. If you prefer to use getCurrentPosition, it's sufficient to keep an active watchPosition while continuing to call getCurrentPosition.

You will also need to increase maximumAge to ensure you receive a cached estimate when one is available. In Chrome, the maximum interval for the wifi polling policy on any platform is currently 10 minutes, so maximumAge should be at least 600000. It's fine to use a larger value.

Long answer: Chrome destroys the WifiDataProvider whenever there are no active listeners, which happens between calls to getCurrentPosition if there are no other geolocation listeners. Typically, when WifiDataProvider is constructed it will kick off a wifi scan and issue a network request to the geolocation service. The time this takes can vary by platform and network conditions but is usually under a second. However, we throttle how frequently Chrome can do this in order to reduce network usage and reduce load on the geolocation service. If Chrome has performed a wifi scan recently, the WifiDataProvider must wait until the throttle timeout expires before starting a new one. The timeout duration varies but can be as long as 10 minutes when wifi data has been scanned multiple times without any major changes.

If WifiDataProvider is created and cannot scan immediately due to the throttling behavior, then NetworkLocationProvider should return a cached estimate if one is available. This could be returned immediately, but NetworkLocationProvider currently has no way to detect the state of the wifi polling policy to know that it should return a cached estimate. So, the current behavior is to return the cached estimate if no new estimate is received after 2 seconds. The timestamp of the cached estimate is updated to the current time to make it "fresh". A cached estimate will not be returned if it's older than 10 minutes.

To fix, we should allow NetworkLocationProvider to query WifiDataProvider to see if it is currently in a state where it can start location acquisition. If not, the cached position should be returned immediately.

To clarify, the workaround is to always have a watchPosition running, and then to set a maximumAge that corresponds to the maximum wifi polling interval of 10 minutes:

var watchId = navigator.geolocation.watchPosition(p=>{});
var gcpOpts = {maximumAge:600000, timeout:0};

// Repeated calls to getCurrentPosition should be quick.
navigator.geolocation.getCurrentPosition(console.log, null, gcpOpts);
navigator.geolocation.getCurrentPosition(console.log, null, gcpOpts);

Unfortunately this workaround doesn't work for us. It still takes the same amount of time for the initial request for location to return a value.

We need to get the user's current location on page load, so it's the initial location request that we need to be quick. Even if we did use the above approach and always had a watchPosition running (initialised at some prior point in the application), the user would be presented with the location permission modal at that point of request, which won't work for us.

That's unfortunate. I have a patch to eliminate the delay for the initial request. If WifiDataProvider is delayed by policy and a network location estimate was received recently (<10 minutes ago), then the cached estimate will be returned with the timestamp updated to the current time.

https://chromium-review.googlesource.com/c/chromium/src/+/1088240

With this patch, requests that hit the network service return in <.5 seconds and requests that return the last-received cached value return in <.1 seconds.

In principle, location acquisition could take a few seconds on some devices, for instance on an Android device with Location set to GPS-only it could take several seconds to generate a GPS fix. It's safest to assume that location estimates may take up to |timeout| ms to return and callers should set a low timeout (and high maximumAge) when cached data is acceptable but a delay is not.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/edc58027851776a636a918c4886f5ac9ede0e77a

commit edc58027851776a636a918c4886f5ac9ede0e77a
Author: Matt Reynolds <mattreynolds@chromium.org>
Date: Mon Jun 11 18:57:00 2018

Return cached network location estimates quickly

The NetworkLocationProvider provides position estimates by scanning
for nearby wifi access points, then sending the set of nearby APs to a
network geolocation service to receive a position estimate in response.
Chrome limits how frequently this can occur to reduce data usage and
reduce load on the geolocation service.

To ensure that a position estimate can be returned quickly when Chrome
cannot scan due to the wifi polling policy, the NetworkLocationProvider
maintains a cache of the last-received position estimate. If no wifi
data is received from the WifiDataProvider and a recent cached estimate
is available, NetworkLocationProvider may return the cached estimate as
if it were fresh.

Currently, the cached position is returned automatically after two
seconds if no new data has been received from the WifiDataProvider.
This CL modifies the behavior so the NetworkLocationProvider can
determine whether WifiDataProvider is delayed for policy reasons. If
so, the provider returns the cached estimate immediately.

BUG= 844061 

Change-Id: If8cbe3c2fad5d0414219190b6644e75ec8159142
Reviewed-on: https://chromium-review.googlesource.com/1088240
Reviewed-by: Reilly Grant <reillyg@chromium.org>
Commit-Queue: Matt Reynolds <mattreynolds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#566084}
[modify] https://crrev.com/edc58027851776a636a918c4886f5ac9ede0e77a/device/geolocation/empty_wifi_data_provider.cc
[modify] https://crrev.com/edc58027851776a636a918c4886f5ac9ede0e77a/device/geolocation/empty_wifi_data_provider.h
[modify] https://crrev.com/edc58027851776a636a918c4886f5ac9ede0e77a/device/geolocation/network_location_provider.cc
[modify] https://crrev.com/edc58027851776a636a918c4886f5ac9ede0e77a/device/geolocation/network_location_provider_unittest.cc
[modify] https://crrev.com/edc58027851776a636a918c4886f5ac9ede0e77a/device/geolocation/wifi_data_provider.h
[modify] https://crrev.com/edc58027851776a636a918c4886f5ac9ede0e77a/device/geolocation/wifi_data_provider_chromeos.cc
[modify] https://crrev.com/edc58027851776a636a918c4886f5ac9ede0e77a/device/geolocation/wifi_data_provider_chromeos.h
[modify] https://crrev.com/edc58027851776a636a918c4886f5ac9ede0e77a/device/geolocation/wifi_data_provider_common.cc
[modify] https://crrev.com/edc58027851776a636a918c4886f5ac9ede0e77a/device/geolocation/wifi_data_provider_common.h
[modify] https://crrev.com/edc58027851776a636a918c4886f5ac9ede0e77a/device/geolocation/wifi_data_provider_common_unittest.cc
[modify] https://crrev.com/edc58027851776a636a918c4886f5ac9ede0e77a/device/geolocation/wifi_data_provider_manager.cc
[modify] https://crrev.com/edc58027851776a636a918c4886f5ac9ede0e77a/device/geolocation/wifi_data_provider_manager.h

Hi Jonathan,

This fix should now be in Canary builds:

https://chromiumdash.appspot.com/commit/edc58027851776a636a918c4886f5ac9ede0e77a

When you get a chance, can you verify that you no longer see the delay?