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: (unassigned) => Thomas Voß (thomas-voss) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to location-service in Ubuntu. https://bugs.launchpad.net/bugs/1604446 Title: getcurrentPosition in oxide does not cause a wake up of the GPS Status in Oxide: New Status in webapps-sprint: New Status in location-service package in Ubuntu: New 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. To manage notifications about this bug go to: https://bugs.launchpad.net/oxide/+bug/1604446/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
