Slightly less drastic than taking away JS rights, what if we cancel the setInterval if any of the code executed as a result of it throws an error?

We need a way to detect that power consumption (or indirectly via CPU activity) is going through the roof for a sustained period of time.

With such an "out-of-the-norm conditions" signal, we could consider a range of aggressive options (throttle all the repetitive APIs: interval, timeout, rAF, etc.) + an easy opt-out.

The challenge with that approach is that I can think of plenty of useful things to do once per 20ms, like complex calculations to produce a frame. Maybe we can use the hint that nothing is changing on screen, but it still seems like the issue here is the error rather than just "high CPU from setInterval"

Good point, the "out-of-the-norm" signal should take into account how much value is being produced. Repeatedly spewing errors in timeout/intervals => low value, no visible changes via rAF => low value.

Easier said than done?

Using the hint that no UI changes to throttle CPU utilization seems interesting. More generally if the user perceived output of the work is low (no screen update, no audio update, etc) then perhaps we can be more confident in throttling CPU utilization.

Perhaps we should be steering devs who want to do expensive computation that doesn't update the UI towards workers, which seem more amenable to throttling and/or running in lower power modes. So perhaps your main thread CPU utilization is throttled based on the ratio of CPU to UI update, with a warning in the console encouraging devs to either reduce the amount of work on the main thread, or move work unrelated to UI updates to a worker. It seems reasonable for us to throttle web workers more aggressively or schedule on a lower power core (assuming that's possible?) since they don't update UI.

What's our policy on using rAF but not updating UI? Perhaps we set a rAF budget that's a function of the ratio of UI updates to rAF callbacks? If no recent UI updates, budget is very low, and if you exceed the budget, we reduce the rAF rate. This allows devs to compute simple statistics in rAF but prevents them from doing heavy work every rAF.

Developers could easily work around this by updating a nonessential UI item in their callback. Is there a way we could address that? Perhaps the best we can do is highlight issues to devs and hope that they take the right action for their users, rather than trying to circumvent the recommendation by continuing to deliver a suboptimal user experience.

RE: repeated errors, it'd be interesting to assess how common this is. If it happens for >1% of page loads, maybe worth fixing. If substantially less, maybe not? What's our threshold for deciding when something is enough of a problem to address it?

Re: the threshold for deciding how much of a problem it is - really depends on how hard it is to implement the fix, and how much we might break if we do it. "Stop setInterval if it throws errors" is nice because it's hard to break something - it's *already* broken.

Beyond the implementation aspect and the potential for breakage, let's not forget the spec-side aspect of interventions.

So before we decide going for specific interventions, we should get a handle on these inefficiencies: this would allow us to know how big the issue is, what flavors exists and surface that data to places that matters (ideally, we wouldn't have to intervene).

Note that rAF itself is the document lifecycle, so reducing the raf rate is equivalent to reducing the frame rate of the tab, ex. going into 30fps mode. 

I like the general leaning of comment 5. I think we should do something like this. The specific ideas in comment 5 sound to complex to me though. It's important that everything we do is simple both for implementation and for explaining it to web authors.

We could throttle the frame rate and timers, if you do... XX rafs/timers without causing any visible raster or audio changes.

We might want to reset that on any user gesture probably.

Dunno. Even as I write that it still seems too complicated. I think we should do something along these lines, but the trick will be finding the right, simple something. :)

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

We have shipped a lot of interventions in the last two years and we're tracking further work in other high-level bugs (i.e. crbug.com/766068), so closing this as Won'tFix