** Changed in: canonical-devices-system-image
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to location-service in Ubuntu.
https://bugs.launchpad.net/bugs/1604446
Title:
getcurrentPosition
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 runni
** Also affects: canonical-devices-system-image
Importance: Undecided
Status: New
** Changed in: canonical-devices-system-image
Status: New => Fix Committed
** Changed in: canonical-devices-system-image
Milestone: None => 13
** Changed in: canonical-devices-system-image
I
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: location-service (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to location-service in Ubuntu.
https://bugs.la
** Branch linked: lp:~mardy/location-service/old-location-1604446
--
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to location-service in Ubuntu.
https://bugs.launchpad.net/bugs/1604446
Title:
getcurrentPosition in oxide does not cause
@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 tha
> 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 b
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 t
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. Po
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
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 foun
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 h
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/qgeopositio
@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 lik
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
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 startUpdat
** Also affects: webapps-sprint
Importance: Undecided
Status: New
** Changed in: webapps-sprint
Assignee: (unassigned) => Alberto Mardegan (mardy)
** Changed in: webapps-sprint
Milestone: None => sprint-25
--
You received this bug notification because you are a member of Ubun
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.
--
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to location-service in Ubuntu.
https://
** Package changed: webbrowser-app (Ubuntu) => oxide
--
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, 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
another site to test this on is https://www.where-am-i.net/
--
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to location-service in Ubuntu.
https://bugs.launchpad.net/bugs/1604446
Title:
getcurrentPosition in oxide does not cause a wake
20 matches
Mail list logo
