1041801 - Cache last known location so watchPosition() can return a good guess immediately

Status: RESOLVED INVALID

(Core :: DOM: Geolocation, enhancement)

Description

[Chris Peterson [:cpeterson]]

Gecko's geolocation service is a singleton so we can cache the last known position there. On desktop and Android, the service's lifetime is that of the browser. On B2G, its lifetime is that of the device, so the cached position won't be cleared until reboot.

Garvan says: "iPhone model always gives last geolocation and then tries to get new data. Best case scenario ends up giving user the [correct] geolocation quickly. Worst case scenario is that it is completely off because geolocation was turned off during travel and then turned on in different location."

Comment 1

[Hanno Schlichting]

We added a request cache as part of #1018383. This cache is smart and will compare the currently available cell/wifi information with that of the cached request. If those are still the same, the outbound network request to the location service is avoided and the cached result is used.

So currently the called always gets a correct result, and sometimes gets it faster from a cache.

This bug calls out for a different kind of cache, which would also give back a potentially wrong position, but could do so even faster, as it wouldn't even have to scan for currently available cell and wifi networks.

Comment 2

[schweerian33]

By Hanno's comment, this doesn't sound like something that is still open for contribution. Is it still open? Can I implement this cache?

Comment 3

[Chris Peterson [:cpeterson]]

Hi! This cache could still be useful. Like Hanno said, bug 1018383 added a *request* cache to avoid network requests to a location server if Gecko (in Firefox browser or OS) sees familiar Wi-Fi networks.

This new cache would remember the last known location, which could be returned to JavaScript:

1. As the initial callback result to a watchPosition() call, followed by more accurate position results from the server.
2. Or the getCurrentPosition() callback result if the network is offline.

The second use case is debatable. Is a "recent but possibly not current" position better than no position result? Maybe the cached position is only valid for a short duration, such as one hour? It would be interesting to test what other desktop browsers, iOS, and Android return when the network is offline.

Comment 4

[Josh Matthews [:jdm]]

The implementation of watchPosition lives in dom/geolocation/nsGeolocation.cpp, along with the rest of the relevant geolocation code for this proposed cache.

Comment 5

[Josh Matthews [:jdm]]

That being said, there already is a cached position stored (see nsGeolocationService::Get/SetCachedPosition) which is used for all requests (getCurrentPosition/watchPosition) based on accuracy and timing restrictions. It's not clear to me precisely what we want to do here that's different.

Comment 6

[:garvan]

There is already a runtime cache in the geolocation service, and a cache for network geolocation requests, leaving only a persistent disk-cached geolocation not implemented. 
This persistent cache had some appeal during the B2G product run where certain devices (or device/software stack combinations) had no assisted GPS, leaving a cold boot device with no network access without a geolocation for up to 15 minutes. 
I am not sure there is a strong argument for having one at the moment, as there is a move away from B2G and solutions to satisfy specific phone vendors. I wouldn't recommend jumping in and coding one this up without a stronger use case than certain phones having missing/poor AGPS.

Comment 7

[:garvan]

invalid, is B2G-related.