- From: Andy Valencia <ajv-cautzeamplog@vsta.org>
- Date: Sat, 24 Mar 2018 14:32:29 -0700 (PDT)
- To: whatwg@lists.whatwg.org
[Philipp Serafin <phil127@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
Received on Saturday, 24 March 2018 21:33:03 UTC