Popular Background Geolocation question on StackOverflow

# Richard Maher (12 days ago)

FYI This question on StackOverflow has now had over 1000 views: - stackoverflow.com/questions/44233409/background-geolocation-serviceworker-onmessage-event-order-when-web-app-regain

Please explain why nothing is happening.

Contact us to advertise here
# Roger Hågensen (7 days ago)

On 2018-03-19 00:25, Richard Maher wrote:

FYI This question on StackOverflow has now had over 1000 views: - stackoverflow.com/questions/44233409/background-geolocation-serviceworker-onmessage-event-order-when-web-app-regain

Please explain why nothing is happening.

It has a accepted solution.

But one key issue is that browers throttle down or even pause inactive windows/background tabs. Partly blame digital currency mining for this, blame the rest on bad programmers running full tilt when they don't need to and DDOS trojans for the rest.

I haven't looked this up, but is there a way to ask the user for permission to run as a background app without performance restrictions? That is the only way I forsee this working across all browsers.

# Philipp Serafin (7 days ago)

If this problem is specific to the "track a route" use-case, and the use-case is sufficiently widespread, would a dedicated "route recording" API make sense?

E.g., a web page could ask the browser to continously record location changes and - at some time at the browser's discretion - push a list of recorded changes to the page.

This would allow the browser to record locations changes with reasonably accuracy without waking up service workers.

It would also provide some hooks for privacy controls: A browser could show a status indicator whenever it's in "GPS recording" mode. It could also notify the user when it's about to push the recorded route to the page and possibly even show the route for confirmation.

Roger Hågensen <rh_whatwg at skuldwyrm.no> schrieb am Sa., 24. März 2018,

19:49:

# Roger Hågensen (7 days ago)

On 2018-03-24 21:15, Philipp Serafin wrote:

If this problem is specific to the "track a route" use-case, and the use-case is sufficiently widespread, would a dedicated "route recording" API make sense?

E.g., a web page could ask the browser to continously record location changes and - at some time at the browser's discretion - push a list of recorded changes to the page.

Hmm! It might. certainly it makes sense to cache location coords since the device may not have a internet connection during the entire time.

In practice it would only need a internet connection at the time of data submission to the site of the webapp, the rest of the time it could be "offline".

This would allow the browser to record locations changes with reasonably accuracy without waking up service workers.

THis part I'm unsure of. Should it be a webapp or a client feature with a API for webapps?

It would also provide some hooks for privacy controls: A browser could show a status indicator whenever it's in "GPS recording" mode. It could also notify the user when it's about to push the recorded route to the page and possibly even show the route for confirmation.

I certainly see the charm and practicality in a webapp asking the client (browser) to start logging GPS coords (it must be user initiated at some point though, like a button/link click). And then the same when stopping it.

A _start function and a _stop function and a _get function would be all that is needed.

The _stop function should be self explanatory. The _start function would allow a argument of milliseconds (or is seconds enough granularity?), which specifies the interval the client should use to record the current GPS and other info.

The _get function of such a API would just return a JSON array of GPS objects, with cords, height and timestamp of the reading, with future expandability for including stats like pressure and moisture and temperature (can't think of anything else). For a cyclist/runner/driver/boater the coords might be useful (to get distance and route traveled). For a camper or woodsman or farmer or who knows what else the moisture and temperature and pressure and elevation may be valuable (the GPS coords would be almost identical for each reading though).

I'm not sure if this would fit under a geolocation API though, perhaps more under a environmental API (where GPS/elevation is just one of many data).

Since the user explicitly (or implicitly) press start there is no need to ask permission. But there should be a possibility to ask for site permisssion and have the webapp autostart, this would allow to run the wwebapp in a browser 24/7 and have it send "live" data to a server. This could make a smartphone a temporary weather station (a smartphone could have a external "weather sensor box" connected for example, providing the sensor input for this API, the browser would just see it as OS provided sensor data).

Sure a Raspberry Pi or some other IOT with some scripting can do this better, but just plopping a smart device to a large battery pack or mains power and leaving it over the night sending live data to a server could be useful. Hundreds if not thousands of these round the world could supplement weather research/sites with that data.

I'd suggest this as a way to detect if such a API is available if ("environment" in navigator) { / environment API is available / } else { / environment API IS NOT available / } It would really need to be it's own thing instead of adding to the geolocation, there should be no issues with both coexisting.

# Andy Valencia (7 days ago)

[Philipp Serafin <phil127 at gmail.com>:]

If this problem is specific to the "track a route" use-case, and the use-case is sufficiently widespread, would a dedicated "route recording" API make sense?

E.g., a web page could ask the browser to continously record location changes and - at some time at the browser's discretion - push a list of recorded changes to the page.

Playing audio is already a special case; the tab with the active

<audio> element will almost certainly not have its setTimeout's

honored until it comes back to foreground. But the "ended" event will get to run, at least long enough to move to the next track. In fact, it can XHR and get to run/play-next on the completion.

(But wait, on slower tablets Firefox doesn't allow quite enough CPU to keep the background mp3 playing. Oops.)

Or think about the iterations in the space of downloads (XHR, service worker background fetch, background sync).

There are lots of apps using long-polling which would also like to have some explicit (standards based) answers to their needs to run when not the current tab--messaging and telemetry apps, for instance.

And here we are thinking about a hand crafted solution for GPS backgrounding.

We're all well aware of the behaviors which make browsers adopt such defensive measures. Are we looking at enough use-cases to think about some sort of general authorization for background resource consumption, rather than continuing the point solution approach?

$0.02, Andy Valencia

# Roger Hågensen (6 days ago)

On 2018-03-24 22:32, Andy Valencia wrote:

There are lots of apps using long-polling which would also like to have some explicit (standards based) answers to their needs to run when not the current tab--messaging and telemetry apps, for instance.

And here we are thinking about a hand crafted solution for GPS backgrounding.

We're all well aware of the behaviors which make browsers adopt such defensive measures. Are we looking at enough use-cases to think about some sort of general authorization for background resource consumption, rather than continuing the point solution approach?

Good point. And my example of a environment API was flawed as I just realized that a heart (pulse) sensor might be highly beneficial to tie into time and GPS and temperature and other sensor data. All this stuff could be lumped into a sensor API (or is there a existing one?)

Another related example would be a loudness tracker, which would use the Microphone to record and calculate a loudness. One particular such use could be a baby monitor, letting you see how much noise/crying the baby does, maybe add in temperature or moisture sensor data if available. Or replace baby with dog or cat to detect barks or meowing while the pet owner is out of the house.

A sensor api and a background permission api should probably be separate as I'll assume there might be other non-sensor uses that a user might want to do background processing. Perhaps a server uptime app, having the app reliably prod a server would be such a use case.

Obviously a dedicated native app could do this much better, but it's a lot quicker to throw something together as a web app. And there is little to no need to roll out updates unlike native apps.

I guess this is a chicken and an egg situation. You won't see use cases unless it's possible to actually implement them. It's not as much a "Should this be possible?" question as it is a "Why isn't this possible?" question.

I've kinda derailed this topic and we've got a three headed hydra now. Geolocation background tracking. Environment/general sensor API with background logging. Background task permission API for sensors or other general purposes.

Regardless of use cases or apis is tied into this, one thing is clear. The user must either implicitly or explicitly initiate or agree to background processing. Some form of UI would be needed to give oversight over background browser tasks too. While I did angle towards smart phones here there is no reason why a desktop can't also run background webapps, and there battery capacity is a non-issue (usually).

Sorry for murkying the waters further on this.

# Roger Hågensen (6 days ago)

On 2018-03-25 07:17, Richard Maher wrote:

    This would allow the browser to record locations changes with
    reasonably
    accuracy *without* waking up service workers.

If you don't like how ServiceWorkers cater for the Fetch API than please take it offline with Jake and W3C.

Um. You missquoted, that wasn't me who said that.

# Roger Hågensen (6 days ago)

On 2018-03-25 07:17, Richard Maher wrote:

If that makes sense for your App the background-fetch already caters for posting location updates to a fleet manager. ... If delayed Batch Processing is acceptable to your site and you don't want geofences then good luck. ... TravelManager register() and unRegister()

I had to look up fleet manager and travelmanager. These are business terms. I did not consider fleet management, nor did I consider targeted traveling advertising/upselling (travelmanager?).

I was looking at this from a non-commercial user standpoint as well as scientific standpoint. Hence why I mentioned "crowd sourcing" weather data and geolocation from smart devices via a webapp, or a health and fitness training app (pulse, distance, altitude etc), or health/wellbeing (baby monitoring, pet monitoring).

But regardless of the intened use or purpose. Splitting things into a whole bunch of APIs and then trying to get permissions working for all of them is going to be a huge pain IMO.

A general purpose permission system and a general purpose sensor api (that can gather gps and various other things like ambient temperature or pulse) would be a better long term goal. It would also be less likely to screw up security this way.

# Philipp Serafin (6 days ago)

2018-03-25 6:29 GMT+02:00, Roger Hågensen <rh_whatwg at skuldwyrm.no>:

On 2018-03-24 22:32, Andy Valencia wrote: [...]

We're all well aware of the behaviors which make browsers adopt such defensive measures. Are we looking at enough use-cases to think about some sort of general authorization for background resource consumption, rather than continuing the point solution approach?

[...] I've kinda derailed this topic and we've got a three headed hydra now. Geolocation background tracking. Environment/general sensor API with background logging. Background task permission API for sensors or other general purposes.

Regardless of use cases or apis is tied into this, one thing is clear. The user must either implicitly or explicitly initiate or agree to background processing. Some form of UI would be needed to give oversight over background browser tasks too. [...]

I think a general solution for background processing would be absolutely desirable. Some additional use-cases would be chats or multiplayer games - i.e. realtime applications where it's important to know whether a current user is still present or has dropped out.

2018-03-24 22:12 GMT+01:00, Roger Hågensen <rh_whatwg at skuldwyrm.no>:

[...]

E.g., a web page could ask the browser to continously record location changes and - at some time at the browser's discretion - push a list of recorded changes to the page.

Hmm! It might. certainly it makes sense to cache location coords since the device may not have a internet connection during the entire time.

In practice it would only need a internet connection at the time of data submission to the site of the webapp, the rest of the time it could be "offline".

This would allow the browser to record locations changes with reasonably accuracy without waking up service workers.

THis part I'm unsure of. Should it be a webapp or a client feature with a API for webapps?

[...]

By "push" I meant triggering a javascript event/callback in the web page that requested the recording in the first place. (Either directly in the corresponding tab/window or in a service worker)

I didn't mean that the browser itself should send the recording over the network. (Though it would certainly be useful if the web page could indicate "wait until there is internet before you call me back", to simplify the case where the page then immediately passes-on the result to a server)

(Anyway, this whole idea seems now obsolete in light of the current discussion, so this is just for the record.)

# Roger Hågensen (3 hours ago)

On 2018-03-25 09:08, Richard Maher wrote:

Splitting things into a whole bunch of APIs and then trying to get permissions working for all of them is going to be a huge pain IMO.

There is no "going to be" Roger. You are not embarking on a green-field development or brain-storming "The Web". We are where we are. I don't care if people want to change things but it is DEFINITELY out-of-scope for the Background Geolocation implementation.

I was a unaware you where the moderator of the Background Geolocation specs or similar. In that case my apologies, I had no intention of pushing things into the specs that do not belong there (it's bad enough in politics).

But I don't understand what you mean by "We are where we are" or why you are against brain storming and I had to lookup the greenfield term but I am unsure if you mean untapped market, new software projects, undeveloped land or if you are referring to an area in Manchester (yes I'm being an asshat on that last one).

I'm also unsure if you are being sarcastic or are actually trying to dictate what I should or should not do. If you are upset that things veered off topic then I'm sorry about that.

To me it looks like you want a commercial backend solution for Uber or Dominos or similar (not end users). Surely these can run apps on tablets or smartphones? Browsers are pretty good but for operational software you want reliability and a consumer browser despite the amazing efforts of the developers so far is not that stable yet. If "always on in the background" is key to a business then a OS run background service is exactly what is needed.

If you need certain functionality implemented and your project is waiting on this then I suggest you make a OS native app instead before your competitors sale past you.

Looking through the WHATWG history I do not like what I see so I'm going to stop communicating regarding this topic, and most likely future topics by you, you come across as excessively abrasive and I'd rather not have to deal with that. You've said in the past that you felt you have been stifled or censored by others, well now you have succeeded in stifling me. I'm having difficulties communicating with you, I can't even imagine trying to work on code or standards implementations with you.

Want more features?

Request early access to our private beta of readable email premium.