Steps to reproduce the problem:
1. Put Android device into powersaving mode from Settings > Battery

2. Create a web page that chains setTimeout calls, e.g.

  function timeoutBug() {
      console.log("Fired at " + new Date());
      setTimeout(timeoutBug, 60000);
  }
  timeoutBug();

3. Wait one minute with screen off. This allows timer to fire once, which creates a new timer during powersave. Turn screen back on. The setTimeout timer fires much later than 1 minute, despite the screen is on again.

What is the expected behavior?
JavaScript developers at large probably expect any setTimeout throttling to go away as soon as screen is turned on and the page is again in view, e.g. if the event is already delayed with respect to its proper timeout value, it should then be fired ASAP.

This matters for web framework called Ember, but possibly others. In Ember, there is a runloop called Backburner which does its work via setTimeout calls. If Ember application asks work to be scheduled during powersave, then Chrome adjusts its timeout value to some future time way past the actually requested timeout value. However, Backburner is not aware of this adjustment. Backburner attempts to avoid clearing and setting timeouts, so it is keeping an estimation of the time when the setTimeout call will fire next time, and if work is scheduled to occur after that estimated time, it simply puts it into a queue to be run next time when the setTimeout will fire.

Because Chrome delays the timeout firing much further than backburner expects, this means that work scheduled to occur in the next millisecond is already way past the time the setTimeout should have fired, so it just goes into the queue. No new setTimeouts are performed to deal with this situation. This interplay between backburner's expectations and Android Chrome's powersaving results in a temporarily stalled runloop in Ember applications.

What went wrong?
Saving power through throttling setTimeout is not a bad idea. But the implementation should stop powersaving as soon as user continues interacting with the device, and should check if any timeouts have elapsed and fire them immediately.

Did this work before? N/A 

Chrome version: 55.0.2883.91  Channel: stable
OS Version: any
Flash Version: