By "lost focus" do you mean that the tab is in the background (not visible)? If so, I think the throttling is expected because we generally don't want background tabs using lots of CPU.

Do you have an example site that broke?

FWIW we don't throttle tabs that are playing audio, although there have been some fixes to this logic in M56.

Thanks for looking into this. You're right, by "loosing focus" I meant the page is not visible anymore.

I created a simple example (https://chrisguttandin.github.io/window-and-worker-timers-test/) which schedules an AudioBuffer with a duration of 500 msec every 500 msec. If everything works fine, it will play a consistent beep sound. Otherwise you will hear notable outages.

I've implemented the same logic with the Window Timers (aka setInterval) and with a little library I wrote called worker-timers which replicates the behavior of setTimeout/setInterval with the help of a Web Worker. Interestingly Firefox 50 works with both approaches.

Albeit my audio related use case, I think there are potentially other good reasons why it would be good to be abled to schedule some work in a background tab more often then once per second. For example if you want to send MIDI notes to connected synthesizers it might be too much if you send out all events for the next second at once.

Unable to reproduce the issue on MAC 10.11.6, Windows 10 and Ubuntu 14.04 using chrome reported version #54.0.2840.98 and latest canary #57.0.2928.0.

Following are the steps followed to reproduce the issue.
------------
1. Navigated to URL: https://chrisguttandin.github.io/window-and-worker-timers-test/
2. Observed a consistent beep sound was played as expected.

chrisguttandin@ - Could you please check this issue on latest canary #57.0.2928.0 by creating a new profile without any apps and extensions and please let us know if the issue still persist or not.

Thanks...!!

I can confirm that the issue does not exist anymore in Chrome Canary 57.0.2931.0 but I can still reproduce it in Chrome 54 on Mac OS X 10.12.1.

Am I understanding you correct that setTimeout/setInterval should behave as expected (without throttling) as long as some audio is running even though the tab might be invisible? Is that behavior somewhere documented?

Thank you for providing more feedback. Adding requester "krajshree@chromium.org" for another review and adding "Needs-Review" label for tracking.

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

Unable to reproduce the issue on Mac 10.12.2, Windows 10 and Ubuntu 14.04 using chrome reported version #54.0.2840.98, latest beta #56.0.2924.28, latest dev #57.0.2950.4 and latest canary #57.0.2963.0.

Following are the steps followed to reproduce the issue.
------------
1. Navigated to URL: https://chrisguttandin.github.io/window-and-worker-timers-test/
2. Clicked on "play with workerTimers" button and observed a consistent beep sound was played as expected.
3. Clicked on "play with windowTimers" button and observed a consistent beep sound was played as expected.

chrisguttandin@ - Could you please check this issue on latest beta #56.0.2924.28 by creating a new profile without any apps and extensions and please let us know if the issue still persist or not.

Thanks...!!

There is another report:  issue 676036 

 Issue 676036  has been merged into this issue.

To be clear, Web Workers being throttled is expected.

This bug and the repro URL seem to be about throttling when Web Audio is involved.

(Blink-Worker bug triage)

skyostil@, do you think we can close this issue based on chrisguttandin@'s confirmation on c#5? Do you have an answer to chrisguttandin@'s question?

> To be clear, Web Workers being throttled is expected.

Slight corrections: currently web workers are never throttled. What we're seeing here is caused by main thread tasks (e.g., handling a postMessage) being throttled.

> Am I understanding you correct that setTimeout/setInterval should behave as 
> expected (without throttling) as long as some audio is running even though the 
> tab might be invisible? Is that behavior somewhere documented?

That's right -- if we detect (non-silent) audio playback, then that tab is exempt from throttling. Essentially all browsers do this to save power but unfortunately it's not very well spec'd. Here's the tracking issue for documenting this: https://github.com/WICG/interventions/issues/5

@krajshree: I can confirm that the issue is not present anymore in Chrome Version 56.0.2924.67 beta (64-bit) on OS X.

@falken & skyos: Many thanks for clarifying the behaviour.