Unable to reproduce the issue on mac 10.13.3 using chrome reported version #65.0.3325.146 and latest canary #67.0.3368.0.

Attached a screen cast for reference.

Following are the steps followed to reproduce the issue.
------------
1. Called navigator.geolocation.getCurrentPosition by pasting it in console.
2. Again called it by pasting in the console.
3. Observed that the callback was called at approx. 1-2 sec.

nik.reynolds@ - Could you please check the attached screen cast and please let us know if anything missed from our end. Also please check the issue on latest canary #67.0.3368.0 by creating a new profile without any apps and extensions and please let us know if the issue still persist or not.

Thanks...!!

Deleted: 820945.mp4 1.7 MB

	820945.mp4 1.7 MB View Download

Sorry, I meant calling the function. Do the following steps:
1) Open console
2) Write the following JS command and press enter. 
   var startTime = new Date(); navigator.geolocation.getCurrentPosition(function() { console.log('Position received. Time elapsed: ' + ((new Date()).getTime() - startTime.getTime()) + 'ms'); });
3) The browser will request permission to access your location. Allow it.
4) When the function ends, the result and the time needed will be logged to the console.
5) Then call the same code again:
var startTime = new Date(); navigator.geolocation.getCurrentPosition(function() { console.log('Position received. Time elapsed: ' + ((new Date()).getTime() - startTime.getTime()) + 'ms'); });
6) It should take more or less the same time, but it will take much longer, or even never come back.

THanks Nik

Thank you for providing more feedback. Adding the requester to the cc list.

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

I have reproduced this in Chrome 65.0.3325.146 (Official Build) (64-bit) on Ubuntu 17.10

The first time works as OP says. After that, it never comes back, unless I pass a timeout in the geolocation options, in which case it comes back after the timeout time with Error Code 3 - Timeout Expired.

Please let me know if more information from me would help, or I have posted this in the wrong place.

Thanks for your time

I've also reproduced this bug. It appears more prevalent on mobile chrome, specifically in an app using a webview, whereby it never get's location anymore.

I also get this on 65.0.3325.146 (Official Build) (64-bit) in Windows 10, after a number (around 3) refreshes. Same error, Timeout Expired.

Able to reproduce the issue on Windows 10, mac 10.13.3 and Ubuntu 14.04 using chrome reported version #65.0.3325.146 and latest canary #67.0.3370.0.

Bisect Information:
=====================
Good build: 65.0.3312.0
Bad Build : 65.0.3313.0

Change Log URL: 
https://chromium.googlesource.com/chromium/src/+log/644fbe520dc19514a80d86a61655ff81ea4b00d5..bd9b9ea0315520281caad474df1fda846e84d6f5

From the above change log suspecting below change
Change-Id: If16c73dfd7d6535346e86d0fab5df24f0c7b297d
Reviewed-on: https://chromium-review.googlesource.com/850444

mattreynolds@ - Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner.
Note: Adding stable blocker for M-65 as it seems to be a recent regression. Please feel free to remove the same if not appropriate.

Thanks...!!

This is WAI.

getCurrentPosition called with default options uses maximumAge:0 and timeout:0xffffffff. In my view, these defaults are poorly chosen and inappropriate for most users. From the spec:

> The maximumAge attribute indicates that the application is willing to accept a cached position whose age is no greater than the specified time in milliseconds. If maximumAge is set to 0, the implementation must immediately attempt to acquire a new position object.

> The timeout attribute denotes the maximum length of time (expressed in milliseconds) that is allowed to pass from the call to getCurrentPosition() or watchPosition() until the corresponding successCallback is invoked.

This means getCurrentPosition with the default options must acquire a fresh position estimate. If it is not available, it will timeout after 0xffffffff milliseconds (~50 days, essentially infinite). Users who want getCurrentPosition to timeout when no position is available should set timeout to a reasonable value.

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 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.

I think this should not be a release blocker. I would prefer that we keep this change since we are still evaluating whether this fix reduces the excessive requests sent to the geo service. As such, I'm resolving this WontFix but am open to suggestions on how we can improve this use case. I'm also interested in reports that this is occurring on mobile devices, which should be able to generate location estimates independently of the network location provider.

wayne.s.covell@, can you share more information on your tests with mobile Chrome? Specifically, can you describe how Location is configured on your Android device? (i.e., "High accuracy" vs "Battery saving" vs "Device only", also do you have the "Wi-Fi scanning" feature enabled under Location>Scanning) Are you testing in an environment with reliable GPS or Wi-Fi coverage?

Testing this, even adding MaximumAge to the request the behaviour seems inconsistent.
In Chrome 65, Mac 10.13.3, I do the following:
1) Open a browser tab, open the console and write:
var startTime = new Date(); navigator.geolocation.getCurrentPosition(function(p) { console.log('Position received. ' + p.coords.latitude + ' ' + p.coords.longitude + ' ' + p.timestamp + ' -  STime elapsed: ' + ((new Date()).getTime() - startTime.getTime()) + 'ms'); }, function(error) { console.log('Error: ' + error);}, {maximumAge: 60*60*1000});
2) It takes some seconds to respond, as expected.
3) I write the same command, and now the response is immediate, thanks to the maximumAge, which is also as expected.
4) Now I open a new tab and type the same command
5) It again takes a very long time to respond, instead of getting the cached position.

This means that a webapp using the correct maximumAge option may still have problems getting a first quick response from getCurrentPosition. Is this expected?

I've confirmed in testing on Mac 10.13.3, Chrome 65.0.3325.181 that the maximumAge option has no effect after page refresh or opening a new tab.  It looks like the rate limit is being applied globally, but the cache only works locally.  This breaks applications that were working in Chrome 64 that rely on user-initiated "search nearby" functionality: previously, we could get results in 3 - 5 seconds, now it can take on the order of minutes.

I am experiencing the same issue on a chrome extension I developed. The new chrome release caused huge increases in response times. As stated by other users, the first instance of a tab load can work quickly but subsequent new tabs or refreshes result in long wait times. Even W3's example page is basically not working on the new chrome release - https://www.w3schools.com/html/tryit.asp?filename=tryhtml5_geolocation

I have implemented the suggested parameters such as maxAge and can confirm that in testing results are retrieved significantly slower than in Chrome 64.

This ticket needs to be re-opened. I've started seeing posts on Stack Overflow and elsewhere about people questioning why they can no longer receive timely location updates in Chrome.

I have had the same results with the proposed parameters as a workaround. Both the suggested fix and the current state are untenable in my opinion, as both degrade user and programmer experience.

We are also experiencing this issue. Workaround does not work. Everyone in our office with latest version of Chrome (Version 65.0.3325.181 (Official Build) (64-bit)) is experiencing this issue. A user in our office with version 64.0.3282.186 is not.

Also, this seems to be geolocation specific. If we use a remote machine (different state) with version 65.0.3325.181, the issue does not occur. 

Reopening as this is indeed a bug. Thanks for reporting this and apologies for prematurely closing it.

The offending CL is being reverted:
https://chromium-review.googlesource.com/c/chromium/src/+/978969

Version 65.0.3325.181

This is happening with this version of Chrome, other browsers like Safari show the GPS location almost instantly, Chrome takes forever with timeout errors, older versions of Chrome also worked very fast. I'm not using watchPosition with defaults.

if (navigator.geolocation) { navigator.geolocation.watchPosition(display_mylocation_update); }

It always have worked for me, tonight while making a new website that used the same code as another website I did one year ago I notice it didn't display right away, sometime I got timeout errors, some it appeared even after a minute, but in Safari, Opera and Firefox it's instantly. 

Applying per comment #6.

I'm seeing this issue on all computers at work that are running Chrome Version 65.0.3325.181

Mobile Chrome version 65.0.3325.109 works fine.

Offending CL was reverted:

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

This bug requires manual review: M66 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), josafat@(ChromeOS), abdulsyed@(Desktop)

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

mattreynolds@ - how safe is this revert? Has it been tested in canary yet? 

I think it should be safe since we are reverting to behavior that was present in a previous version of Chrome. The offending CL was intended to fix a geolocation quota issue where we suspected Chrome was sending more requests than it should. We identified a scenario where this was possible -- Chrome has a policy to restrict the frequency of wi-fi scans, but the policy wasn't being followed in most circumstances. The CL applied the policy in more situations, so reverting the CL means that Chrome will be able to perform wi-fi scans more frequently.

We had seen some decrease in geolocation API calls after this CL reached stable, so reverting it is likely to cause it to increase again. We've implemented some DOS protections to keep us under quota while we fix the issue but this may result in more geolocation outages.

The revert hasn't been tested in Canary yet. I was advised to request a merge for this ASAP as an alternative to another M65 respin. The merge can wait until we can test this in Canary as long as we can still get it into the next M66 beta.

let's wait until this has baked in canary. Let's take it for next week's beta.

Matt - how does it look in canary?

I tested on Windows 10 with Chrome 67.0.3383.0 (Official Build) canary (64-bit). Geolocation API calls succeed with no delay on subsequent calls, even from another tab. This matches my expectations after rolling back the offending CL.

Approving merge to M66. Branch:3359

The revert is merged to M66:

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

 Issue 823284  has been merged into this issue.

Just a heads up, M66 Stable cut is on April 12th, 10 days away. This issue is marked as RB-Stable for 66. Please make sure to address this issue prior to stable cut. Thanks! 

We're not planning any more M65 releases. Pls target fix for M66. 

Pls mark bug as fixed if nothing else is pending.

The offending CL has been reverted in trunk and the M66 branch and should be live in the current Canary and next M66 Beta build.

 Issue 828559  has been merged into this issue.

Version 70.0.3538.110 (Offizieller Build) (64-Bit)
The isssue is still there:
Version 70.0.3538.110 (Offizieller Build) (64-Bit)
in console:
var startTime = new Date(); navigator.geolocation.getCurrentPosition(function(p) { console.log('Position received. ' + p.coords.latitude + ' ' + p.coords.longitude + ' ' + p.timestamp + ' -  STime elapsed: ' + ((new Date()).getTime() - startTime.getTime()) + 'ms'); }, function(error) { console.log('Error: ' + error);}, {maximumAge: 0});
result: Position received. 48.xxxxxxxx 11.xxxxxxx 1543176373680 -  STime elapsed: 253222ms

Also the watchPosition seems to working buggy:
let start = Date.now();
let startRouteWatchPosition = function(position) {
    let end = Date.now();
    let elapsed = (end - start)/1000;
    start = end;
    console.log('Elapsed time: <span style="color:red;">' + elapsed + '</span> seconds.');
}

let startRouteError = function(error) {
    console.log('Error occurred. Error code: ' + error.code);

}

let options = {
       enableHighAccuracy: true,
       timeout: 5000,
       maximumAge: 0
   };
watchPositionId = navigator.geolocation.watchPosition(startRouteWatchPosition, startRouteError, options);

result:
Elapsed time: <span style="color:red;">422.482</span> seconds.
Elapsed time: <span style="color:red;">126.568</span> seconds.
Elapsed time: <span style="color:red;">101.982</span> seconds.
Elapsed time: <span style="color:red;">1.996</span> seconds.
Elapsed time: <span style="color:red;">218.163</span> seconds.
Elapsed time: <span style="color:red;">0.37</span> seconds.
Elapsed time: <span style="color:red;">91.46</span> seconds.
Elapsed time: <span style="color:red;">1.995</span> seconds.
Elapsed time: <span style="color:red;">21.634</span> seconds.
Elapsed time: <span style="color:red;">1.996</span> seconds.
Elapsed time: <span style="color:red;">151.184</span> seconds.
Elapsed time: <span style="color:red;">1.985</span> seconds.
Elapsed time: <span style="color:red;">69.094</span> seconds.
Elapsed time: <span style="color:red;">40.155</span> seconds.

in firefox the values are very fine:
Elapsed time: <span style="color:red;">4.842</span> seconds. openlayers.3ba3f127.js:29:155549
Elapsed time: <span style="color:red;">5.002</span> seconds. openlayers.3ba3f127.js:29:155549
Elapsed time: <span style="color:red;">4.859</span> seconds. openlayers.3ba3f127.js:29:155549
Elapsed time: <span style="color:red;">5</span> seconds. openlayers.3ba3f127.js:29:155549
Elapsed time: <span style="color:red;">4.839</span> seconds. openlayers.3ba3f127.js:29:155549
Elapsed time: <span style="color:red;">5.002</span> seconds. openlayers.3ba3f127.js:29:155549
Elapsed time: <span style="color:red;">4.791</span> seconds. openlayers.3ba3f127.js:29:155549
Elapsed time: <span style="color:red;">5.001</span> seconds. openlayers.3ba3f127.js:29:155549
Elapsed time: <span style="color:red;">4.776</span> seconds. openlayers.3ba3f127.js:29:155549
Elapsed time: <span style="color:red;">5</span> seconds. openlayers.3ba3f127.js:29:155549
Elapsed time: <span style="color:red;">4.774</span> seconds. openlayers.3ba3f127.js:29:155549
Elapsed time: <span style="color:red;">5</span> seconds. openlayers.3ba3f127.js:29:155549
Elapsed time: <span style="color:red;">4.778</span> seconds.

Experiencing same issue - Version 70.0.3538.110 (Official Build) (64-bit) - MacOS

Even maps.google.com fails to get current location from browser with: "Your Location could not be determined." (when not showing the associated phone's location)

This seems to work however on a Win 10 machine with same Chrome version...

Can someone reopen and investigate this issue, please? Thanks