Returning a cached position as freshly acquired with an ongoing watchPosition call

[nondebug]

The steps for Acquire a position describe how to determine if a cached position estimate satisfies the maximumAge option. Passing maximumAge=0 should force a "fresh" position to be acquired.

In typical browser implementations, a call to watchPosition causes the browser to subscribe to the system's location API to receive fresh position estimates. The estimates received from this subscription are broadcast to all Geolocation API callers that have are currently awaiting a position update. Rather than providing new estimates at a regular interval, most system location APIs only provide a new estimate when it is significantly different than the previous estimate. If the device is not moving then the provider may not generate new position estimates.

If there is an ongoing watchPosition when a new call to getCurrentPosition or watchPosition is made when the cached position's age is greater than maximumAge, callbacks may not be called until the system location API returns a new estimate (which may never happen) or the call times out. Ideally, callers should always be able to receive a fresh estimate and should not be blocked by requests from other callers. Given that the browser is already monitoring changes to the position estimate and should be notified if the previous position estimate is no longer accurate, it seems reasonable for the browser to treat the most recent estimate as if it were freshly acquired.

I checked the current behavior in Safari, Firefox, and Chromium on macOS. Chromium and Safari share the same behavior where an ongoing call to watchPosition can block other callers from receiving estimates until the system location API returns a fresh estimate (it's likely this behavior existed before the engines forked). In Firefox, each new call to getCurrentPosition or watchPosition triggers a new position update which is broadcast to all callers. Instead of acquiring a new position, Firefox reuses the cached position but sets its timestamp to the current time. The timestamp-adjusted position update is returned to all callers, including ongoing watchPositions. This behavior ensures Geolocation API callers always receive a position estimate without delay and all callers see the same view of the underlying position data. However, it also makes it possible for watchPosition callers to observe when other geolocation API calls are made by checking if consecutive updates differ only by the timestamp.

I want to propose we allow the browser to treat the most recent cached position estimate as fresh (that is, the browser can adjust the most recent position estimate's acquisitionTime to satisfy maximumAge) if the cached estimate was received while the browser was subscribed for notifications on changes in device location, and the subscription is still active. The browser should only deliver the timestamp-adjusted estimate to the new caller(s), not any ongoing watchPositions, to prevent other callers from observing the new call.