This issue seems to be similar to that of Issue 753242, Hence duplicating into it. Please feel free to undupe if both are not similar.

Thanks!

no problem, can you re-open the old issue?

Geolocation works for the first time, till a full page refresh.
Then it throws (after small delay):
PositionError {code: 3, message: "Timeout expired"}

I have to close and reopen the browser to make it work again.

Re-separating this from crbug.com/753242 as I doubt that it's the same as that prior fixed issue, and Zac provided exact repro steps here. For posterity, the issue resolved in crbug.com/753242 was running out of API quota.

I can repro the behavior described in the OP on Linux stable (65.0.3325.146) and canary (67.0.3369.0). I'm going to investigate as I suspect that this might be related to the changes that we've made for servicification of geolocation. Will report back what I find and give the bug back if I determine I'm not the right person to keep making progress on it.

+mcasas@ for historical knowledge of geolocation

Hello,

I dug into this and found what looks to me like the root cause. AFAICT, it's long-standing behavior in Chrome (not related to Ke He's servicification), and seems to be a question of whether Chrome is correctly implementation the getCurrentPosition() spec. 

Here is the specific repro case:

- Make an initial request, which gets satisfied with the initial position.
- Let the cache period of that returned position expire.
- Make another request without the position having changed (e.g., do this on your desktop machine).
- Observe that the second request times out. If you alter the code to skip firing the timeout expiration callback, the second request will hang forever.

Here is the root cause:

- When the browser receives the second request, it will not return anything from that request until there is a position change (cf. https://cs.chromium.org/chromium/src/device/geolocation/geolocation_impl.cc?q=geolocation_impl.cc&sq=package:chromium&l=129, https://cs.chromium.org/chromium/src/device/geolocation/geolocation_impl.cc?q=geolocation_impl.cc&sq=package:chromium&l=171, and https://cs.chromium.org/chromium/src/device/geolocation/geolocation_impl.cc?q=geolocation_impl.cc&sq=package:chromium&l=157).

The above-described behavior seems to have been in place at least since before
https://codereview.chromium.org/841133002/ in early 2015, which did some refactoring here but preserved this pre-existing behavior (in particular, on the "before" side of that CL, there was already the model that geolocation updates were set from the browser to the renderer only in response to an update from the underlying source, meaning that the behavior in the above-described repro case would have been identical to what it is now).

AFAICT (but I'm not an expert), this behavior violates the spec here:
https://www.w3.org/TR/geolocation-API/#geolocation_interface, which
indicates that the implementation of getCurrentPosition() should start a
location acquisition operation (step 3). The Chrome browser-side
implementation does nothing to "obtain the current location" in response to a request to get the current location; it simply waits passively for an update from the underlying platform-specific source with which it is registered.

The question of the correctness of this behavior wrt the spec is not one that I'm best-suited to answer. Back to mattreynolds@ for triage on answering that question.

would that explain https://bugs.chromium.org/p/chromium/issues/detail?id=542923 ?

Thanks for digging into this, Colin.

In my view this is probably the correct behavior, ignoring any crbug.com/753242 related quota issues. As such I'm closing this as WontFix.

Given that this is seen on desktop, it's probably related to my recent change to the network location provider.

https://chromium.googlesource.com/chromium/src/+/bd9b9ea0315520281caad474df1fda846e84d6f5

getCurrentPosition takes timeout and maximumAge options. The default values for these are 0 for maximumAge (meaning cached position estimates should not be returned; Chrome should acquire a fresh estimate) and 0xffffffff for timeout (~50 days, essentially infinite). I think these defaults are poorly chosen and inappropriate for most users.

The problem is that on some platforms we cannot acquire a fresh position estimate due to other constraints. For instance, on wifi-enabled desktops and laptops that lack GPS hardware, the position estimate may be generated by a network request to a Google service. To help prevent abuse we limit how often Chrome can make such requests.

Chrome, by default, will scan for nearby wifi APs every 10 seconds and send the collection of discovered MAC addresses to a Google service, which returns a location estimate. If no change is detected between the most recent two scans, it backs off to 2 minutes. If no changes are detected again, it backs off further to 10 minutes. This means it may take as long as 10 minutes to acquire a fresh position estimate on a stationary device that lacks dedicated hardware for geolocation. Users who want to quickly acquire a cached position estimate should set maximumAge to at least 10 minutes.

Lately we have been receiving excessive requests to the geo service, which has resulted in outages. We investigated the issue and discovered that Chrome's implementation of the network request rate-limiting behavior was broken if the user called getCurrentPosition frequently without an active watchPosition. The bisected CL moves the polling policy to a global instance so it persists across calls to getCurrentPosition. This does cause getCurrentPosition to timeout in more situations where previously it could have generated a fresh estimate.

In the typical scenario for a stationary desktop or laptop computer where the network location provider is the primary provider, the set of nearby APs will not change more frequently than once every 10 minutes so. As such, we are likely to have already backed off to the longest interval. In the codepen example, we set maximumAge to either 0 or 2 seconds. I expect the call to succeed the first few times and then fail repeatedly until the 10 minute interval is complete and another scan is performed. I think it would be more appropriate for this example to avoid this by using a maximumAge of 10 minutes (600000) or greater.

As an alternate suggestion, users who are frequently calling getCurrentPosition should consider watchPosition as it is better suited for this purpose.

zac.spitzer@: I think this is unrelated to the bug where we sometimes fire both TIMEOUT and POSITION_UNAVAILABLE.

+1 to what Matt said regarding geoCurrentPosition arguments: "I think these defaults are poorly chosen and inappropriate for most users."

Not Sure If Tangential:

Matt, am I right in thinking that this is also related to the discussion we had on your crrev.com/c/703976 last year about bringing the maximumAge default value into compliance with the spec (i.e. making it 0 not infinity)?

And which you continued with blink-dev in:
https://groups.google.com/a/chromium.org/d/msg/blink-dev/G29x6z_VkUs/7ickv4LGBgAJ) 

Summary:
crrev.com/c/703976 -> Fixed maximumAge default value
crrev.com/c/850444 -> Fixed situation where as you wrote 'the provider is destroyed and recreated rapidly it considers each scan to be "first"'

I.e. crrev.com/c/703976 + crrev.com/c/850444 together will effectively apply the maximumAge=0 default more often than just crrev.com/c/703976 by itself?

I'm seeing this behavior on a desktop on ethernet with the wi-fi adaptor disabled behind a static ip, what's the logic involved when there's no APs available?

amoylan@:

I think these are distinct.

In the maximumAge issue, we were getting "fresh" updates from the Android location provider that weren't actually fresh. To fix, we made Chrome actually check the timestamp of the estimate it receives so stale estimates can be rejected.

In this issue, we're using the network location provider so the timestamp of the position estimate is decided by Chrome itself. We never receive "stale" estimates because we set the timestamp to the time when the network request was made.

zac.spitzer@:

This is a good question, I need to dig into this some more. It appears that the behavior may be platform-dependent due to the way we determine whether a wifi scan was successful. It may be that a system with a disabled wlan adapter is treated differently than a system with no wlan adapter.

Which desktop OS are you seeing this on?

I use Win10 64-bit, but i also see similar behavior with my laptop on wifi, on a different network

I tweaked the testcase with some better logging, including run numbers
https://output.jsbin.com/mudaxem

Yeah, it looks like there may be some inconsistency here between platforms. I see different behavior for GetAccessPointData between my Windows and Linux desktops (neither has a WLAN adapter).

I opened a new bug to investigate this:

https://crbug.com/822394