1482733 - Geolocation.watchPosition() doesn't work in background on Android O and above

Status: NEW

(Core :: DOM: Geolocation, defect, P2)

Description

[matt.panaro]

User Agent: Mozilla/5.0 (Android 7.1.1; Tablet; rv:61.0) Gecko/61.0 Firefox/61.0
Build ID: 20180807170231

Steps to reproduce:

I have a personal webpage that uses navigator.geolocation.watchposition to geotrace my runs/bike-rides.  This used to work well, even when the phone display was off and it was in my pocket during the activity.


Actual results:

I got a new phone with Android Oreo, which comes with new background-app limitations  (specifically, these limitations, I think: https://developer.android.com/about/versions/oreo/background-location-limits & https://developer.android.com/about/versions/oreo/background#services ).  GPS updates now immediately stop in firefox after the phone's display is powered off, meaning no geotrace is successfully recorded by my webpage.


Expected results:

frequent (~once per second), high-accuracy GPS updates should still be received by the background firefox process, as was the case before Oreo.

Comment 1

[Jan Henning [:JanH]]

If we want to do something about this, we'd have to shoehorn some mechanism for notifying the embedding app when notification updates start and end here: https://dxr.mozilla.org/mozilla-central/source/mobile/android/geckoview/src/main/java/org/mozilla/gecko/GeckoAppShell.java#335 [1]

Then the embedding app can either just do nothing (default state) or show/hide a foreground notification in response (in case of Firefox maybe using our NotificationClient/NotificationService mechanism), in order to have location updates working in background as well. For Firefox, it might also make sense to reuse the Location Services notification channel added for the stumbler for this notification, too.


[1] Alternatively we could simply bypass GeckoAppShell and just catch the corresponding observer service notifications [2] directly and show/hide a notification in response, but providing a generic Java API that all GeckoView-embedding apps can use to show a notification if they want is probably the preferable solution.
[2] https://dxr.mozilla.org/mozilla-central/rev/4e56a2f51ad739ca52046723448f3129a58f1666/dom/geolocation/nsGeolocation.cpp#798-799,876-877

Comment 2

[Liz Henry (:lizzard) (relman/hg->git project)]

Too late to change this for 63 but we may want to plan to fix this for 65 or later.

Comment 3

[:sdaswani]

Tagging Andreas for a product decision on priority.

Comment 4

[Andreas Bovens [:abovens]]

It seems like this would be something we probably won't fix in Fennec (at least not for now), but should investigate for GeckoView. Looping in Chris for visibility.

Comment 5

[Chris Peterson [:cpeterson]]

I'm surprised this worked in the first place. :) I would expect Fennec to pause or throttle geolocation callbacks when the phone display is off. Does this work in Chrome?

For privacy-sensitive Focus users, geolocation (especially when the browser is backgrounded) is likely an uncommon use case. For Fenix, we should decide whether we want to support this use case and then either fix it for Android >= O or disable it for Android <= N.

Comment 6

[Richard Maher]

Please see https://github.com/RichardMaher/Brotkrumen for a complete working example of how Mozilla and other UA developers should implement the TravelManager (analogous to PushManager) in ServiceWorkers to facilitate supported, battery-friendly, and authorized background geolocation.

Yes you have been the only browser vendor to support this. For a chuckle see recent #ChromeDevSummit tweet: - https://twitter.com/VerboDei/status/1062201017926729729

For complete background see complete background discussions see https://github.com/w3c/ServiceWorker/issues/745

*Please* don't let W3C sideline this to the Generic Sensors group!

Comment 7

[Richard Maher]

See also https://bugzilla.mozilla.org/show_bug.cgi?id=1254911

Comment 8

[Chris Peterson [:cpeterson]]

(In reply to Richard Maher from comment #7)
> See also https://bugzilla.mozilla.org/show_bug.cgi?id=1254911

Thanks for the link. For both privacy and battery usage concerns, we should

Comment 9

[Chris Peterson [:cpeterson]]

... try to fix this bug for Fenix.

Comment 10

[Chris Peterson [:cpeterson]]

Not a release blocker for Fenix MVP

Comment 11

[James E. A. (any) [:codegeek98]]

I'd like to make the following suggestion for how this could be implemented from a UX perspective:

(i) If a webpage, or at least a PWA, is sent to the background while watchPosition() is already running, the position will continue being watched.
(ii) If this happens, a notification will appear while any background webpage or PWA is watching the user's location.
(iii) Once the location watch has been dropped and the notification vanished, the app must be put back in the foreground before it can resume access.
(iv) The domain or PWA-name will be listed in the notification, and the access can easily and quickly be stopped or revoked from the notification.

This is not only how (essentially) all mobile browsers currently handle webpages playing audio in the background, but also how existing navigation apps such as Google Maps and Waze handle background location access, so there's a tremendous precedent for this; I also believe it genuinely cuts an extremely good balance between usability/battery/alert-fatigue/etc, and potential privacy concerns.

It would, I believe, not violate the principle of least-surprise at all, and I suspect it would, further, set a precedent for how to keep the user informed of background location access that I will prove sorely needed as the W3C prepares to publish its recommendations concerning the more-"passive" background-geofencing.

Comment 12

[Robert Kaiser]

My web app for recording my GPS positions, which I have used for years, has become useless due to this bug now that I switched to Android 10, even if I "install" it to the home screen via Fenix Nightly.

Are there any plans to work on this for future Fenix versions?
I would love if I do not have to resort to native apps to record GPS tracks (where this works without issues), esp. as I have put a lot of work into making this web app work over the years.

Comment 13

[Karl Dubost💡 :karlcow]

This might be a duplicate https://webcompat.com/issues/81320