See  issue 616519  - it's a work in progress, so I guess the behavior may be enhanced, but you'll probably have to provide a compelling argument and examples, use cases, etc.

Use case:

I have a simulation of a chemical plant that runs in the Chrome browser. It needs to do CPU intensive calculations so it spawns multiple web workers so it can run on all available cores. 

The web workers do calculation tasks which take 50-100ms to complete. Before they can do another task they need to exchange state information with one another. 

As far as I know, the web workers can't talk directly to one another (although now I see there is something called "channel messaging" that I will have to look into) so I use the main page to coordinate their communication. 

The user may want to check the status of the simulation, change some parameters, and then send the tab to the background, browse other things on the web, and then come back to check the progress.

Since this change, the background calculations only run at 1/5th the speed when the user isn't looking.

In regard to  issue 616519 : I don't think its appropriate to make breaking changes to the web in order to improve efficiency. Maybe you can flag pages that are consuming a lot of power while in the background by maybe putting a little battery icon on the tab for instance, but why do something that is going to change the way pages work? There are plenty of pages that render all sorts of things that are probably use annoying advertisements, but you can't you go and break the way timers work. Maybe you can make a "power saver" extension, just like there are advertisement blockers.

If you really must have this change, then at least give a programmatic way to opt out. Maybe a function call where the user sees a banner that say "this page is requesting permission to run fast background calculations, this may impact your battery life. Allow?".

Could you please provide a sample HTML file to reproduce the issue from test team end.

Here is a simplified example of the issue described in comment 2. In the real use, the work loads actually take a good amount of time (~150 ms).

Deleted: background-event-regression.html 8.2 KB

background-event-regression.html 8.2 KB View Download

Kenji-san, could you route this bug to somewhere appropriate?

bruceceng: re  issue 616519 , this has long been the case in Safari (not just cross origin iframes) and apparently Firefox too [1]. We consider polling as an anti-pattern. Please let us know if the channel messaging is not appropriate for your use case.

blink-scheduling: just to confirm, does the behavior in Safari/Firefox also impact web workers?

[1] https://github.com/WICG/interventions/issues/9#issuecomment-228045095

I am going to look into channel messaging. However, see Mohre's answer:

http://stackoverflow.com/questions/5927284/how-can-i-make-setinterval-also-work-when-a-tab-is-inactive-in-chrome

This is what was broken in the recent chrome update. Also, the use cases in the comments, like a metronome, or smoothly fading volume are probably broken.

It sounds like what is being throttled here is the message *back* from the worker to the main page (which is backgrounded). Is that right? I'm not sure if Firefox/Safari throttle onmessage, but I believe we do.

Re #8: we don't throttle background tabs that are playing audio.

Re #9: Correct, the worker.onmessage event in the backgrounded main page is now being throttled. This is a change from Chrome 53 (I believe it was working as recently as this, certainly within the last 2 months). I'm guessing its related to the changes in  issue 616519  as pointed out in Re #1.

I just tried my sample page in Firefox 49.0.2 and it currently does *not* throttle the onmessage.

Re #9: Your comment about not throttling background tabs that are playing audio also appears to be false now. I added the following lines to my sample page (in comment #4), started the audio playing, and the page still exhibited the same throttling behavior when moved to the background.

  <audio controls>
   <source src="Led Zeppelin - Stairway To Heaven Live.mp3" type="audio/mpeg">
   Your browser does not support the audio element.
  </audio>

Hmm, could you check again with Chrome Canary? I just checked with a tip-of-tree build and throttling was not getting activated while there was audio playback (trace attached).

I think rogue background tabs burning CPU with unnecessary work is a big enough problem that we want to be a bit aggressive here. I'd argue that simulations like this are a somewhat of a special case. In case it is useful, note that there is a command line flag that can be used to disable throttling:

--disable-background-timer-throttling

Deleted: trace_background_audio_playback.json.gz 2.4 MB

trace_background_audio_playback.json.gz 2.4 MB Download

Just tried with this version 56.0.2909.0 canary (64-bit) and saw the same issue.

Steps to reproduce: 
1. Edit the html to point to a song on your computer
2. Open the HTML in the foreground.
3. As long as HTML stays in foreground, Simulated years/second ~0.05
4. Start music playing
5. Move tab to background for a few seconds
6. Move tab back to foreground. Simulated years/second is now < 0.05

Also, I don't think this issue is directly related to the traditional form "throttling", because I ran restarted chrome with --disable-background-timer-throttling and the condition persisted. I think one of the recent changes has introduced another form of background throttling that isn't disabled by the flag or by playing audio.

The good news for me is that it appears I will be able to solve my particular problem with MessageChannels (I've attached a sample for posterity), but this will represent substantial rework. 

Besides the chrome flag, I think you should create a way to request disabled background throttling which presents the user with an option bar and then disables *all* forms of throttling.

Deleted: background-event-regression-with-music.html 8.3 KB

background-event-regression-with-music.html 8.3 KB View Download

Deleted: background-event-messagechannel.html 12.1 KB

background-event-messagechannel.html 12.1 KB View Download

One more use case which was impacted:

Webpage decodes streamed audio packets (assume codec not available in browser) in a worker. Worker posts messages to main thread for playback. Main thread checks timestamps of decoded packets and skips few packets, if required, to maintain realtime playback.

Issue:
Worker uses 250ms length of audio data. When worker posts 4 messages, they get queued up and processed in batch. Timestamps are messed up now as we get messages every sec and main thread skips first 3 and only plays last packet. Audio will be choppy.

Making 1 sec packet length solves the problem but it means relying on Chrome to use 1Hz for post messages.

I think similar problem could happen with encoding audio where encoding happens in background thread. (Using WebRTC is not solution for all browsers/codecs)

Ideally AudioWorker should avoid the postMessage to mainthread altogether but it is not implemented across browsers and even in Chrome changes seem to be not finalized: https://bugs.chromium.org/p/chromium/issues/detail?id=469639

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

Marking as WontFix as a part of scheduling bug review.

Generally it's expected that a page which user can't see (or hear) won't consume any resources.

Throttling of the main thread tasks is expected and we're looking into throttling webworkers as well. We're working on allowing user to explicitly allow to run some pages in background.

Please feel free to file any bugs for future issues.