The `timeout` option doesn't make sense for watchPosition

[saschanaz]

Here's what the current spec says:

1. The watchPosition() algorithm just passes the whole options to "request a position" steps.

2. The "request a position" steps says it should wait for a change at step 7.5.1:

   Wait for a significant change of geographic position. What constitutes a significant change of geographic position is left to the implementation. User agents MAY impose a rate limit on how frequently position changes are reported.

3. But before that, at step 7.3 it calls "acquire a position" again with the whole options.

4. And "acquire a position" creates the timeout task regardless of the existence of watchId.

And in the description of timeout it has a non-normative note that says:

An options.timeout value 0 can cause immediate failures.

And browsers work differently:

1. With timeout: 0:
   • Safari halts immediately
   • Chrome immediately triggers error callback and still calls success callback
   • Firefox silently does nothing.
2. With timeout: 1:
   • Safari errors immediately and still proceeds to call success callback
   • Chrome behaves similar to Safari, but on Windows the initial call succeeds without any error
   • Firefox keeps triggers the error callback as if it's `setInterval(errorCallback, 1);
3. With timeout: 1000:
   • The initial call succeeds without any error for both Safari and Chrome. The following calls still trigger the error callback after 1 sec. The success callback is triggered later in any case.
   • Firefox still repeatedly triggers the error callback.

Certainly Firefox is bugged here, but I'm not sure the point to time out for watchPosition when it's still expected to proceed after that. We are getting webcompat reports where websites consider the error callback as a full error instead of just "taking time to get the initial position". (See the "Blocks" references in https://bugzilla.mozilla.org/show_bug.cgi?id=1920302)

Should we consider removing timeout from watchPosition, or is there a known real-world use case for the initial timeout?

[reillyeon]

Thinking out loud, the reason for a timeout parameter to getCurrentPosition() or watchPosition() is to have a built-in setTimeout() that informs the site when a location isn't available. This is useful as otherwise the success callback might never be called and that too could cause issues. If we were designing this today we'd probably avoid this parameter and integrate an AbortSignal instead.

From a compat perspective, aside from bugs and corner cases, I think the issue is that under different conditions it simply takes more or less time to acquire a position and so any value of timeout is probably "wrong" sometimes and will result in unexpected site behavior. For watchPosition() this is particularly bad because the time between position updates can be quite long and it's unclear whether it's correct to generate a timeout simply if there hasn't been a significant change within the timeout, even if the previous result is perfectly accurate.

I suspect it's more robust for sites to implement their own timeouts (if they want them) and only have the browser invoke the error callback if there's an actual error condition which would prevent the site from getting a new location (e.g. a failure of the geolocation hardware, if the browser depends on GPS, or a change in the user's permission choices).