Able to reproduce the issue on reported chrome version 65.0.3325.162 using Mac 10.12.6 hence providing Bisect Info
Note: Issue is not seen on Ubuntu 14.04 & Windows-10
Bisect Info:
================
Good build: 65.0.3312.0
Bad build: 65.0.3313.0

You are probably looking for a change made after 528465 (known good), but no later than 528466 (first known bad).

https://chromium.googlesource.com/chromium/src/+log/10c1f7014dd8a888dc7e0e3830355c1756abf48f..4e0435834ec440a2e4938abe90946c2dfa73027c

Reviewed-on: https://chromium-review.googlesource.com/850444

@Matt Reynolds: Please confirm the issue and help in re-assigning if it is not related to your change.
Adding ReleaseBlock-Stable as it is seems a recent break, feel free to remove it if not applicable.

Thanks!

> Any components that are location bound went into an infinite loading loop or crashed (instantly or after a timeout)

Can you provide more information on your observation? Do you have a example geolocation API call that was failing?

Per offline chat with  mattreynolds@, we're not blocking M65 stable release for this.

@mattreynolds : 

Any geolocation call is failing after the second page load. First noticed on a my page which uses simple geolocation to determine the closest object to me. Afterwards, even tried it on Google Maps and after a page refresh, Maps can't locate my position (worked fine before the update, worked fine on a second machine that had the v64 and after upgrading the second machine to v65, it failed) 

Removing ReleaseBlock-Stable as this is probably WAI.

The bisected CL fixes a bug in Chrome where previously we were not enforcing rate limiting on network geolocation requests. (Chrome periodically scans for nearby wi-fi access points and uploads their MAC addresses to a Google service, which returns a location estimate.) The fix enforces the rate-limiting behavior, leading to timeouts in some instances where previously Chrome could have requested a fresh estimate.

It's possible there's a bug in how Chrome responds when there is no wi-fi available or the wi-fi APs haven't changed in some time (signalling that the device is probably stationary). I've opened a bug to investigate this:

http://crbug.com/822394

The current behavior will scan for wi-fi APs every 10 seconds as long as each scan produces significantly different results. Once the results stabilize, Chrome backs off to 2 minutes, and then 10 minutes for the longest interval. (On Mac we use alternate intervals of 2 minutes / 5 minutes / 10 minutes but otherwise the behavior is the same.)

getCurrentPosition takes timeout and maximumAge options. With the default values, timeout is 0xFFFFFFFF (effectively infinite) and maximumAge is 0. Using zero for maximumAge means that only position estimates generated after the call to getCurrentPosition may be returned. This is an issue when Chrome cannot generate a new estimate on demand due to other requirements (e.g., network request rate limiting) and can lead to long delays before the API call returns an estimate or times out.

To address this, consider using a large value for maximumAge (larger than 10 minutes) to indicate that stale estimates of this kind are acceptable.

We are also investigating if we can modify Chrome's behavior to spoof the age of network location estimates when we know the device has been stationary for some time, which would allow us to return a "fresh" estimate even when the wi-fi polling policy would not allow a new wi-fi scan.

http://crbug.com/821948

We are seeing this issue in Chrome and Firefox on various OSs. It does not seem to be related to the number of times the page is loaded, it seems to returning location info after random periods time from a couple of ms up to 10 minutes.

eg.
https://www.nationaltrust.org.uk/search
1. Click on Enter a location
2. Select Use my location

Confirming we're seeing this same issue on 65.0.3325.181 on various versions of OSX (including 10.13.3 (17D47)).

Geolocation tends to work first time page is loaded. After reload it doesn't (at least for some apparently random time).

Our app is using watchPosition with a timeout of 10000.

NOTE: This works fine on mobile where GPS is returning the location. Also seems fine on Windows.

We are seeing this issue in Chrome 65.0.3325.181 on OSX 10.13 (17A365). 
Geolocation fails after page refresh. 
Our app is using leaflet.js map.locate function that uses watchPosition.

Marking this as a duplicate of 820945. Thanks for reporting this, everyone who commented on the bug.

The bisected CL has been reverted and this bug should be fixed in the current Canary builds. Please take a moment to verify that you are no longer experiencing the bug in Chrome Canary:

https://www.google.com/chrome/browser/canary.html