Site with geolocation API access granted can get location updates while in the background
Categories
(Core :: DOM: Geolocation, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox92 | --- | fixed |
People
(Reporter: konrad, Assigned: marcos)
References
Details
(Keywords: parity-chrome, parity-safari)
Attachments
(1 file)
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_6) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.1.2 Safari/605.1.15
Firefox for Android
Steps to reproduce:
- Go to https://output.jsbin.com/yapihuf
- Allow geolocation API access to the site
- Switch to a different tab, or app, for 5s
- Come back to the tab from #1
Actual results:
Site was receiving updates while in the background (page will show multiple new entries with a "Last update 1s ago" message).
Expected results:
Site should not receive updates when its not focused (page should only show one new entry with a "Last update 5s ago" message).
This affects Firefox on desktop and Android. It does not affect Chrome or Safari.
It's not required by the Geolocation API specification ATM, but it's a privacy concern and it's being discussed here: https://github.com/w3c/geolocation-api/issues/48
Comment 1•4 years ago
|
||
Bugbug thinks this bug should belong to this component, but please revert this change in case of error.
Updated•4 years ago
|
Comment 2•4 years ago
|
||
We will need to spec this out as part of https://github.com/w3c/geolocation-api/issues/48
Comment 3•4 years ago
|
||
The component has been changed since the backlog priority was decided, so we're resetting it.
For more information, please visit auto_nag documentation.
when the document is hidden from view, silently drop position updates on the floor. This aligns with Chrome and Safari.
Hi Jens, not sure who to ping about this bug for guidance (i.e., not sure who owns geo now). I wouldn't mind some initial feedback to make sure I'm on the right track before adding tests?
FWIW, the test site works as expected when the patch is applies:
https://output.jsbin.com/yapihuf
Comment 6•4 years ago
|
||
(In reply to marcos from comment #5)
Hi Jens, not sure who to ping about this bug for guidance (i.e., not sure who owns geo now). I wouldn't mind some initial feedback to make sure I'm on the right track before adding tests?
Well, I am the triage owner, so you chose the right entry point. The change looks reasonable to me and is something we should probably do. For further review please refer to :echen. Thanks for your help!
Updated•4 years ago
|
Hi Edgar, I've done some more exploring and this is insufficient. I think I need to set up visibility change event listeners if the document is hidden, then kick off the update request after the document becomes visible again.
Comment 8•4 years ago
|
||
(In reply to marcos from comment #7)
Hi Edgar, I've done some more exploring and this is insufficient. I think I need to set up visibility change event listeners if the document is hidden, then kick off the update request after the document becomes visible again.
Yeah, for watchPosition()
, I think it makes sense to kick off an update request once the document becomes visible.
But for getCurrentPosition()
, Chrome seems just ignore the request, i.e. no PositionCallBack or PositionErrorCallBack get called even after document becomes visible? Chrome's behavior is also odd, I think we should at least call PositionErrorCallBack if PositionCallBack isn't triggered. But I guess doing it might be a compatibility risk...
(In reply to Edgar Chen [:edgar] from comment #8)
(In reply to marcos from comment #7)
Hi Edgar, I've done some more exploring and this is insufficient. I think I need to set up visibility change event listeners if the document is hidden, then kick off the update request after the document becomes visible again.
Yeah, for
watchPosition()
, I think it makes sense to kick off an update request once the document becomes visible.But for
getCurrentPosition()
, Chrome seems just ignore the request, i.e. no PositionCallBack or PositionErrorCallBack get called even after document becomes visible? Chrome's behavior is also odd, I think we should at least call PositionErrorCallBack if PositionCallBack isn't triggered. But I guess doing it might be a compatibility risk...
I did some thinking and I think what I had originally might work... basically, we can just drop the position updates on the floor until the document becomes visible/fully active... I'll write some tests to confirm it works.
Updated•3 years ago
|
Assignee | ||
Comment 10•3 years ago
|
||
Comment 11•3 years ago
|
||
Comment 12•3 years ago
|
||
Backed out for causing mochitest failures in test_hidden
Backout link: https://hg.mozilla.org/integration/autoland/rev/e69cfd0df6fc246c478ee575d7f63bed26e63848
Assignee | ||
Comment 13•3 years ago
|
||
Ah yeah, the test will fail on Android... that makes sense. We are doing tab switching.
Assignee | ||
Comment 14•3 years ago
|
||
Try Android and few others explicitly:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=c41e071c5019ff87ca0448d015c23e98b5929ae4
Try auto/fuzzy:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=8963ad40b358c3b0f13ee58c2f7dc739aab81380
Assignee | ||
Comment 15•3 years ago
|
||
Hi Sandor, just wondering, I normally do ./mach try
before merging a patch, but it fails to catch things like that above.
I've now used try chooser
to make sure that Android is tested.
However, is there something else I should be doing in the first place so that ./mach try
checks across all OSs?
Comment 16•3 years ago
|
||
Hi, another alternative you could try is using the Fuzzy selector ./mach try fuzzy
for choosing jobs
From what I can see on your try push, only the android builds have been triggered.
Assignee | ||
Comment 17•3 years ago
|
||
Thanks Sandor, that's exactly what I needed!
Assignee | ||
Comment 18•3 years ago
|
||
Try (Android/Mochitests):
https://treeherder.mozilla.org/#/jobs?repo=try&revision=4ce95737e3397b1b3a298a4e727b033f6666b443
Comment 19•3 years ago
|
||
Comment 20•3 years ago
|
||
bugherder |
Description
•