getcurrentPosition in oxide does not cause a wake up of the GPS

Bug #1604446 reported by Alan Bell
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Canonical System Image
Fix Released
Medium
Unassigned
Oxide
New
Undecided
Unassigned
webapps-sprint
New
Undecided
Alberto Mardegan
location-service (Ubuntu)
Fix Released
Undecided
Thomas Voß

Bug Description

A browser based application that wants to use position can call getCurrentPosition
https://developer.mozilla.org/en-US/docs/Web/API/Geolocation/getCurrentPosition
or watchPosition
https://developer.mozilla.org/en-US/docs/Web/API/Geolocation/watchPosition

maps (such as google maps) and navigation applications will typically use watchPosition which will cause location services to turn on the GPS chip and get a new location for the device.
non-map applications that just want location aware context for things such as weather or local stores e.g. https://www.aldi.co.uk/store-finder do not subscribe to updates with watchPosition. They just call getCurrentPosition and expect a decent enough position to use.

Ubuntu Touch returns the last known position from the cache when getCurrentPosition is called, and then fails to turn on the GPS. It should block until it has a decent position and return good data to the success callback. It certainly shouldn't return a bad position and then fail to make an effort to get a good position.

The result of this bug is that you can go to a location aware web page, it will think you are somewhere else entirely, and refreshing will not improve the situation, you have to open a mapping application that uses watchPosition and wait for a fix to be obtained before going back to your location aware web page and refreshing to get good data.

Related branches

Revision history for this message
Alan Bell (alanbell) wrote :

another site to test this on is https://www.where-am-i.net/

Olivier Tilloy (osomon)
affects: webbrowser-app (Ubuntu) → oxide
Revision history for this message
Chris Coulson (chrisccoulson) wrote :

I'm not sure what Oxide is meant to do here - we query the location service via the qtpositioning API. There is no API for "waking up the GPS" AFAICT.

David Barth (dbarth)
Changed in webapps-sprint:
assignee: nobody → Alberto Mardegan (mardy)
milestone: none → sprint-25
Revision history for this message
Olivier Tilloy (osomon) wrote :

And to expand on this: even when requesting a single position with getCurrentPosition, oxide calls in to QGeoPositionInfoSource::startUpdates()¹. I wonder if there’s a bug in QtPositioning, or maybe incorrect documentation, as on my laptop (which doesn’t have a GPS chipset), when calling startUpdates() I’m getting a positionUpdated() signal almost instantly, with what seems to be the last known position, and its timestamp is 2016-03-24, i.e. 4 months ago. So it looks like it’s not even trying to get an updated position. Maybe it does, but prior to this it returns the last known position, and since we requested only one position (not regular updates), the source is shut down right away, thus not giving it time to get an actual update?

¹ https://doc.qt.io/qt-5/qgeopositioninfosource.html#startUpdates

Revision history for this message
Alberto Mardegan (mardy) wrote :

Part of this is similar to bug 1551686.

In addition the fix proposed in that bug (which won't help in this case, though) we have two options:
1) completely get rid of caching in location-service
2) When the client specifies maximumAge as 0, oxide should keep discarding any position update which carries an old timestamp

I think that implementing #2 is a good thing regardless of #1, so I'd suggest that at least this part would be fixed in Oxide.

Revision history for this message
Olivier Tilloy (osomon) wrote :

@Alberto: the maximumAge parameter is not exposed in the chromium content API. See https://cs.chromium.org/chromium/src/content/public/browser/location_provider.h.

Additionally, see my previous comment: I’m seeing the same issue on my laptop, which is not running the location service. It looks like QtPositioning will instantly return the last known position even when an actual update has been requested.

Revision history for this message
Olivier Tilloy (osomon) wrote :

The issue I’m seeing on my laptop seems to be specific to the geoclue location plugin: the last known position is serialized on disk, and it’s always emitted at startup, regardless of whether an update was requested: https://github.com/qt/qtlocation/blob/dev/src/plugins/position/geoclue/qgeopositioninfosource_geocluemaster.cpp#L289

Revision history for this message
Olivier Tilloy (osomon) wrote :

I just had a chat with Thomas, and it appears that the GeoPositionInfoSource as implemented in qtubuntu-sensors always returns the last known position first on purpose, before starting to request updates. This is similar to what the geoclue plugin does.

However it’s not clear that this should be happening: QGeoPositionInfoSource has a lastKnownPosition() method¹ that allows clients to query the last know position explicitly, so I don’t think a call to startUpdates() should return that last known position first. Instead clients should be calling lastKnownPosition() themselves to get a first approximation, and then call startUpdates() to get an updated position (and thus expect that the first response will be with an accurate position).

¹ https://doc.qt.io/qt-5/qgeopositioninfosource.html#lastKnownPosition

Changed in location-service (Ubuntu):
assignee: nobody → Thomas Voß (thomas-voss)
Revision history for this message
Alan Bell (alanbell) wrote :

worth noting that the last known position isn't an estimate of where you are with low and decreasing accuracy (like a cell tower position is), where you have a rough position and an error radius, so you are in that circle with some kind of probability distribution on where you can expect to be found. It is a high accuracy position of where you have been at some point in the past, beyond a few minutes old it really is a very bad thing to store and return - it isn't an approximation of the current position.

Revision history for this message
Alberto Mardegan (mardy) wrote :

Thomas, maybe we should drop my MP [1] and completely disable returning the LKP if it's more than a couple of minutes old, as Alan proposes, and instead add a LastKnownPosition property to the location service D-Bus interface, and query that in the qtubuntu-sensors's lastKnownPosition() method?

If my understanding is correct, please let me know if you'd welcome help to implement this.

[1]: https://code.launchpad.net/~mardy/location-service/old-location-1551686/+merge/293075

Revision history for this message
Olivier Tilloy (osomon) wrote :

Right, but as long as the location service doesn’t return the last known location when updates were requested, it’s okay. There’s a specific method for querying the last known location, and it does what it says on the tin. Note that the last known position isn’t necessarily very accurate either. Position objects have attributes that convey the horizontal and vertical accuracy.

Revision history for this message
Alan Bell (alanbell) wrote :

Last known position is almost always going to be a full house level GPS lock on the place where you last turned off a map application, probably the last destination you navigated to. Might also be a full GPS lock on the last place you took a photograph. This could be a problem for implementing things like http://pooperapp.com/ on Ubuntu Touch ;)
As long as getCurrentPosition doesn't just return LKP and calls startupdates() and returns the first position from that (I am a little unconvinced it calls startupdates at all, because then repeated calls would presumably eventually work and they don't?)

Revision history for this message
Olivier Tilloy (osomon) wrote :

> I am a little unconvinced it calls startupdates at all, because then
> repeated calls would presumably eventually work and they don't?

startUpdates() is being called, but because oxide gets a position right away (the last known one), it calls stopUpdates(), which prevents the GPS from actually being woken up at all.

Revision history for this message
Thomas Voß (thomas-voss) wrote :

@Mardy: Any help is welcome :) I think we want to first drop providing the initial estimate altogether to get this bug fixed asap. We can then go ahead and investigate whether we want to expose the last known location to applications.

@Alan: I think it's still an estimate and we should provide that data to applications if they want to leverage it. Point being that it is up to them to filter/interpret the last known position in a sane way if they explicitly request it.

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in location-service (Ubuntu):
status: New → Confirmed
Changed in canonical-devices-system-image:
status: New → Fix Committed
milestone: none → 13
importance: Undecided → Medium
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package location-service - 3.0.0+16.10.20160811-0ubuntu1

---------------
location-service (3.0.0+16.10.20160811-0ubuntu1) yakkety; urgency=medium

  [ Alberto Mardegan ]
  * Don't sent last known position to new sessions (LP: #1604446)

  [ Scott Sweeny ]
  * Enable running location-service on Snappy Ubuntu Core

  [ Thomas Voß ]
  * Make sure that we are not racing with the timeout handler.

 -- Thomas Voß <email address hidden> Thu, 11 Aug 2016 08:27:10 +0000

Changed in location-service (Ubuntu):
status: Confirmed → Fix Released
Changed in canonical-devices-system-image:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers