This could also be used by ads or stuff like background monero miners to prevent killing the user's battery...
> There probably is not much of a difference for a website if user is low in power than if it is low in memory. There should be then just one flag/event really: low resources (catch-all for: battery, memory, CPU time, storage etc.). But browser could just emit please-save event and give a second or so to complete. Then decrease timer intervals significantly.
Or is the idea that you want to get as many timer calls in as possible before the device finally dies?
I meant increase intervals or decrease the number of them in a period of time.
It's definitely not cool with me, an insane waste of electricity.
Still, I prefer giving a "mining" contribution to a website operator (who actually needs some kind of revenue to live) over watching obnoxious ads and having my every move end up in dozens of tracker databases, in addition to hackers distributing malware over ad networks.
I am not indebted to anyone to allow them to use my machine's resources for their monetary goals.
If they want to make money off of me, make it clear -- I can respect that if I value your content. But exploiting browsers that are not caught up with latest security practices is being a scum and I will not tolerate it, ever.
Most will use it to try to push you harder "before your battery runs out"
An example of this would be an app like Uber charging you more if your battery level is low. They already know that people with low battery are willing to pay more: https://www.forbes.com/sites/amitchowdhry/2016/05/25/uber-lo...
Though a battery percentage is not really useful for this as it could mean many things. My current main phone at 25% could last until tomorrow quite easily, my previous main device had at most a couple of hours left at that point. A simple "warning level" API would be more useful, allowing the app to register for events like "less than one hour of power left", "power loss likely in the next ten minutes", "entering super-power-saver mode" & "manual shut-down starting" and/or poll for the same flags. That way the device, which is much better placed to monitor such properties, can manage the warning levels perhaps with an off switch in case users don't want apps to know. Of course, you might have to enforce limited resource use in response to low power events, and you shouldn't allow much time between emitting "entering super power saver" events and actually entering the mode (which will shut off browser tasks until the mode is left).
So while there is a valid use case, that doesn't rely on trusting advertisers or other hogs to do something nice, the API as wasn't fit for that purpose and making something that is might be more complicated than you'd first think (so perhaps not worth the effort for the few apps that would actually make use of it).
The system can crash, hang, forcefully reboot or otherwise die at any moment, without warning. All it takes is one "oopsy", for the phone to hit the ground and the battery to fly off.
If there is important data that needs to be preserved, applications should already be committing it to non-volatile locations periodically.
The moral of the story is that Web API development is now driven at least partially by "How will advertisers abuse this new API?", and probably will be moreso over time, and that has, ahhh, interesting interactions with the forces pushing the browser into being the universal VM platform.
App developers should be already working on these conditions by default. You should already have a game save system that can expect client shutdown or disconnection at any time.
That said, I could see a 15% or less warning but your mobile OS is doing that anyway, so why bother.
Why risk it?