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 -- 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
