Intent to Ship: Expensive Background Timer Throttling

[Alexander Timin]

Contact emails

alt...@chromium.org

Design doc

Time-based renderer task throttling

Summary

Some badly behaved pages (e.g. javascript ads and analytics scripts) consume a lot of CPU even when the tab is in the background, impacting browser performance and battery life and ruining user experience. The idea is to place a limit on how much processing resources background pages are allowed to use.

The proposed throttling operates as follows:

• Each WebView has a budget (in seconds) for running timers in background.

• A timer task is only allowed to run when the budget is non-negative.

• After a timer has executed, its run time is subtracted from the budget.

• The budget regenerates with time (at rate of 0.01 seconds per second).

Link to “Intent to Implement” blink-dev discussion

Intent to Implement: Expensive Background Timer Throttling

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

Demo link

https://fiddle.jshell.net/vvL0e9x3/show/light

Interoperability and Compatibility Risk

Initial testing by enabling the feature locally by a small number of developers did not expose any problems. However, there exists a possibility of breakage of a major site, so we want to ship this feature via experiment-controlled rollout. This will allow us to quickly respond to issues (if any), by changing throttling aggressiveness or disabling throttling completely if necessary.

Firefox: No public signals

Edge: Positive

Safari: No public signals

OWP launch tracking bug

crbug.com/650594

Link to entry on the feature dashboard

https://www.chromestatus.com/feature/6172836527865856

Requesting approval to ship?

Yes.

[Darin Fisher]

This is really great, but are there any exceptions (e.g., for background pages playing sound)?

-Darin

[Alexander Timin]

Yes, pages playing sound are exempt (that is inherited from current mechanisms to align background timers to once a second).

[Kentaro Hara]

Non-owner LGTM.

keishi@ and others have also confirmed that ads on background tabs are one of the largest power consumers, so the budget-based timer throttling will help a lot to save the power consumption of Chrome.

Also the budget-based timer throttling enables us to implement a background tab suspension in a better manner (i.e., we can just set the budget to a small value). The background tab suspension is a key technology of Memory Coordinator to massively drop memory from background tabs.

--

Kentaro Hara, Tokyo, Japan

[Rick Byers]

I'm excited about this, thanks for working on it!

Background tabs on Android are generally 100% suspended, right?  So this is primarily a desktop feature, or is there non-trivial Android impact too?

Since this is an intervention, can you comment (probably best in the design doc) on the extent to which it will adhere to the intervention design guidelines?  Eg. how will we measure it's positive impact, will we give advice to developers for detecting when it's active in case they need to adapt / fail?  Will there be a console warning or anything to help developers understand when they're being impacted?

How exactly do you define "background"?  Eg. is the visible tab of an unfocused (even occluded) window "background"?  I'm wondering if there's any advice we can give users who want to keep some expensive app running while they're actively using another window.

I'm a little nervous about other scenarios (like background music player) that we might be breaking without realizing it.  Is there any chance it would be easy / useful to use RAPPOR to get a list of top sites that would be most impacted by this in practice, just to skim for any potentially interesting use cases (eg. video editing or other computation-heavy scenarios)?

Thanks!

   Rick

[Alexander Timin]

Background tabs on Android are suspended after 5 minutes in background. Minor improvements may happen, but major win is expected on desktops.

Background tab is the one which is not visible to the user (WebViewImpl::setVisibilityState is the source of truth); unfocused windows are considered foreground. This mechanism is the same as currently exists for background timer alignment.

Audio-playing sites are exempt from throttling (even after for some time after audio stopped playing). 

Also for your convenience I copied intervention guidelines here:

Predictability: Throttling mechanism is well-defined. High-level description (only pages with significant CPU load are going to be impacted). 

Avoidability: Heavy computations on UI thread is not best practice, so only bad-behaved pages are going to be impacted. 

Transparency: Console log message is generated when tasks we throttled for non-trivial amount of time (small throttling is not reported because we already align timers in background tabs). Also developer can monitor start time of tasks and detect intervention programmatically.

Data-driven: Main UMA metric that we are monitoring is BackgroundMainThreadLoad. It is percentage of time that renderer spends executing javascript tasks. Given that >90% of pages have low CPU usage, we are expecting changes to high percentiles (95, 99), not average (95 percentile is 10% load, 99 percentile is 90% load). 

Alexander

[mark a. foltz]

+miu as an FYI.  We should make sure tabs with an active content capture device are exempted as well, if they aren't already.

[Yuri Wiitala]

I think we're good to go here for tab capture:

1. There has been recent work on detecting when there is audible sound coming from the renderer, and turning off timer throttling in that case.

2. During tab capture, the captured renderer is explictly *not* told when a browser tab becomes backgrounded. Thus, a captured renderer should always behave as if it thinks it's in a foreground tab.

3. Otherwise, I think the proposal here can only improve the tab capture experience. For example, if a badly behaved page's JavaScript is eating up CPU, we want the new throttling logic to engage so that we have more CPU for capture and real-time video encoding (which will improve quality).

[Philip Jägenstedt]

If WebViewImpl::setVisibilityState is the trigger, then I think web developers can simply use document.visibilityState and the related events to know when throttling may happen. To have an API to know that it has definitely happen seems nice for predictability in principle, but if aren't any known good reasons to do a lot of work on the main thread while in the background, then I'm inclined to think we should punt on that.

Rick, do you have any further concerns? LGTM1 for me.

[Rick Byers]

Thanks for the details.  LGTM2

A couple more minor questions inline.

On Thu, Nov 17, 2016 at 5:26 AM, Philip Jägenstedt <foo...@chromium.org> wrote:

If WebViewImpl::setVisibilityState is the trigger, then I think web developers can simply use document.visibilityState and the related events to know when throttling may happen. To have an API to know that it has definitely happen seems nice for predictability in principle, but if aren't any known good reasons to do a lot of work on the main thread while in the background, then I'm inclined to think we should punt on that.

Rick, do you have any further concerns? LGTM1 for me.

On Thu, Nov 17, 2016 at 12:26 AM 'Yuri Wiitala' via blink-dev <blin...@chromium.org> wrote:

I think we're good to go here for tab capture:

1. There has been recent work on detecting when there is audible sound coming from the renderer, and turning off timer throttling in that case.

2. During tab capture, the captured renderer is explictly *not* told when a browser tab becomes backgrounded. Thus, a captured renderer should always behave as if it thinks it's in a foreground tab.

3. Otherwise, I think the proposal here can only improve the tab capture experience. For example, if a badly behaved page's JavaScript is eating up CPU, we want the new throttling logic to engage so that we have more CPU for capture and real-time video encoding (which will improve quality).

On Tue, Nov 15, 2016 at 4:31 PM, mark a. foltz <mfo...@chromium.org> wrote:

+miu as an FYI.  We should make sure tabs with an active content capture device are exempted as well, if they aren't already.

On Mon, Nov 14, 2016 at 4:26 PM, 'Alexander Timin' via blink-dev <blin...@chromium.org> wrote:

Background tabs on Android are suspended after 5 minutes in background. Minor improvements may happen, but major win is expected on desktops.

Background tab is the one which is not visible to the user (WebViewImpl::setVisibilityState is the source of truth); unfocused windows are considered foreground. This mechanism is the same as currently exists for background timer alignment.

So this means, for example, when we do a blog post about this we should tell users that they can always drag a tab into a new window if they don't want it to be throttled while they're working in another tab, right?  I assume we don't know when a window is occluded by some other window at the OS level (or if we do, you could always have a tiny bit peaking out to keep it considered "foreground").

Audio-playing sites are exempt from throttling (even after for some time after audio stopped playing). 

Also for your convenience I copied intervention guidelines here:

Predictability: Throttling mechanism is well-defined. High-level description (only pages with significant CPU load are going to be impacted). 

Avoidability: Heavy computations on UI thread is not best practice, so only bad-behaved pages are going to be impacted. 

Transparency: Console log message is generated when tasks we throttled for non-trivial amount of time (small throttling is not reported because we already align timers in background tabs). Also developer can monitor start time of tasks and detect intervention programmatically.

Great!  Does / will the console warning include a URL for more details (eg. at least the chromestatus entry for now, ideally a blog post)?  Can we publish a sample test page that shows this (both small throttling without a warning, and large throttling with a warning) in action to help explain what's going on?

  

Data-driven: Main UMA metric that we are monitoring is BackgroundMainThreadLoad. It is percentage of time that renderer spends executing javascript tasks. Given that >90% of pages have low CPU usage, we are expecting changes to high percentiles (95, 99), not average (95 percentile is 10% load, 99 percentile is 90% load). 

Yep, that makes perfect sense.  I was looking at the 99th percentile with Ojan last week - bringing that down will be huge!

[Chris Harrelson]

LGTM3, but I agree with Rick's comments about further improvements to the rollout communication.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[samuel.t...@gmail.com]

It appears this has rolled out in Chrome 56 beta, causing us significant breakage.

We run a real-time trading site that moves quite a bit of tick data down the pipe. We also send heartbeats back up the pipe, but our timers are being throttled by as much as 130 seconds.

Without any mechanism to hint that a given timer is high or low priority this will cause significant breakage across the web.

We still want to be able to deliver notifications to users and keep our heartbeats running. Aside from playing a 0-volume sound file, what options do we have?

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Daniel Bratell]

Since I like to make sure that the most obvious is out of the way, have you checked if it's possible to optimize your application to use less time?

Audio file hacks wouldn't be recommended. If that practice spreads and pages ones again start draining batteries there would have to be more interventions and then your application would become slow again. 

Do you know if there is any small tuning that would help your application?

/Daniel

--

/* Opera Software, Linköping, Sweden: CET (UTC+1) */

[Samuel Reed]

Re: tuning, yes, this is an effort I am starting anew, but we already do quite a bit of good-citizen work that I wouldn't expect most applications to do: we are coalescing real-time updates and batching renders at requestAnimationFrame, we have a highly optimized view pipeline that only does minimal work on change, and so on.

While I appreciate the aim of this change it is fundamentally at odds with what the web really is. This change optimizes for the web as a publishing platform and content consumption platform, but the web is also an _application platform_ and timers must be semi-reliable for it to remain usable as such.

Our use case is simple; we have real-time tick and trade data coming down a websocket. This data occasionally produces events we need to notify on. The same could be true of, say, any collaboration platform or chat application. That incoming data requires some processing to be useful. For instance, chat messages may need to be parsed for mentions so we can alert via native notifications or by changing the tab title. This change makes our job much harder.

In testing, even with our updates throttled to a 25 second timer I am seeing Chrome delaying by as much as 130 seconds (!!). This is also not controllable or introspectable by us; the heuristic is a mystery. Unbreaking our application may involve such hacks as running 1000ms timers, measuring delay, and using that to determine how much work we can get away with before we're about to get throttled. This throttling is also causing clients to miss timed heartbeats, which causes websocket disconnects and resyncs; this is actually producing *more* work as the user switches tabs back and forth and thus more CPU usage in the average case.

It is a good goal to want to do something about bad behavior in advertising scripts, but that should start by producing incentives for that industry to reform its terribly-coded scripts, not by breaking the web as an application platform without giving us room to control our destiny.

I see at a few changes that would be required to make this not break the web:

* Application developers will need a way to view their current timer budget so they can determine how much work they can do before throttling.
* Application developers will need to be able to schedule 'high priority' and 'low priority' timers, and these timers should have different budgets. Such high-priority timers would allow us to at least be able to send pings/heartbeats reliably.
* Applications need an escape hatch. For instance, if the user has indicated that they wish to receive notifications from a page, what good is that if the page is throttled such that these notifications never arrive? What if the page wants to auto-save data at intervals or even communicate with other tabs?

It will be a lot of work to continue down this path without causing significant breakage. I urge the Chromium team to reconsider this application-breaking change, for the sake of developers, the web platform, and the havoc that will soon come to the bug tracker and mailing lists if this hits stable.

Daniel Bratell

January 20, 2017 at 3:48 AM

samuel.t...@gmail.com

January 19, 2017 at 4:16 PM

You received this message because you are subscribed to a topic in the Google Groups "blink-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/blink-dev/XRqy8mIOWps/unsubscribe.
To unsubscribe from this group and all its topics, send an email to blink-dev+...@chromium.org.

[Alexander Timin]

Hi Samuel, 

Thank you for providing valuable feedback. 

The throttling heuristic is described in the first email in this thread. The high-level overview is that we want timers to run 1% of the time while in background (10ms every second) and throttling delays ensure that average load stays under this figure.

To respond to your concerns we will be limiting maximal throttling delay to 30 seconds effective now. Also we will be looking into disabling aggressive background throttling for webpages with active (e.g. websockets) connections.

The long-term vision for the web platform is the following: main thread is considered to be UI thread, and should be idle when page is backgrounded. ServiceWorkers should be used for all background tasks. 

To unsubscribe from this group and all its topics, send an email to blink-dev+unsubscribe@chromium.org.

[Samuel Reed]

Thanks for the response and for considering our use case.

As a suggestion, making this throttling sensitive to the Notification
permission (or even a separate permission) seems like an elegant
solution to me, as a user is unlikely to response positively to
Notification requests from the typical type of site that has advertising.

Also, if there were a way to signal to Chrome that I would like a timer
to actually fire on time (for, say, a WebSocket heartbeat), it would be
great to have a syntax or option for this with the caveat that
misbehaving fns will also be throttled, but on a separate counter.

Re: ServiceWorkers, will a similar sort of throttling eventually apply?

[Daniel Bratell]

On Fri, 20 Jan 2017 13:45:48 +0100, Samuel Reed <samuel.t...@gmail.com> wrote:

Re: tuning, yes, this is an effort I am starting anew, but we already do quite a bit of good-citizen work that I wouldn't expect most applications to do: we are coalescing real-time updates and batching renders at requestAnimationFrame, we have a highly optimized view pipeline that only does minimal work on change, and so on.

I was actually thinking of tuning of the throttling, not your application, but I see that altimin has already done some and there seems to be a couple of useful ideas to make your application and ones like it work better.

/Daniel

[gap...@gmail.com]

Before implementing that kind of a change and recommending to use ServiceWorkers at least wait for others to actually support SW. You don't want to have

if(IE){ fallback() }

happening all over again.  

To unsubscribe from this group and all its topics, send an email to blink-dev+...@chromium.org.

[shac...@gmail.com]

Will this affect timers only (setTimeout, setInterval) or the entire event-loop (window.postMessage, MutationObserver, etc'..)?
Many applications today use npm packages transpiled for the web which use underlying Node-like logic that relies on building blocks like https://www.npmjs.com/package/asap - which in their turn can totally break if the latter is the case.

Re: background work should be ran in service worker

I couldn't agree more, but AFAIK SW isn't mature enough for all applications: 

1. Video/Audio based manipulation is not yet possible (due to progressive video's long-lived request nature)

2. P2P applications that use webrtc and sync states and pings between users (in the background as well)

If taking example 1 into account, you mentioned if there's sound in the tab the budget rule will be avoided entirely, and timers will be semi reliable?

[sc...@scottparadis.com]

Can the timer states be normalized when the background tab is brought back into the active state? We have a variety of timers used for different gradual engagement mechanisms. If the timer accuracy fluctuates while backgrounded, this ok. But when we bring it back to an active state, we need them to be accurate. 

Broadly speaking, this seems like a VERY disrupting change to a fundamental truth about time that many web applications have come to rely on. It seems rather shortsighted to punish the web as a whole for the poor coding practices of a few.

I would urge more thought and analysis on how to target the worst offenders based upon the memory and CPU usage rather than a blanket policy that disrupts even the simplest and benign of timers.

[d...@danilink.com]

This is very bad news for our online chat system. How are we going to keep the connection persistent? What is going to happen with the sockets? IMHO there should be a way to ask the user for permission to keep the timers. Breaking them unexpectedly will break the logic in A LOT of applications in very unpredictable ways.

Please think twice before shipping this!

[Rick Byers]

Alexander, can you please clarify a couple points about the design (I think there's some confusion on this thread):

1. It's only timers (i.e. application polling) that are throttled, right?  Eg. in the case of an active websocket (or other network connection) when a network response is received, it's still given to the application immediately as normal.
   
   
2. If a user (eg. for the trading app discussed here) really wants to allow the tab to do expensive timer-based polling, they can always drag that tab out into it's own window.  It will then be considered a "foreground" tab and will not have any throttling applied.  That's certainly the behavior I'm seeing on your demo page.

It sounds to me like those (coupled with the 30s max limit you just pushed for heartbeat-type scenarios) should largely address the concerns raised here, right?  If anyone has a concrete example of an application that is really broken by this, please file a bug with details and repro steps (and feel free to mention it here) so that we can investigate in detail.

Otherwise I don't see an obvious reason why this can't continue to ship in 56 as planned.  Using >1% of CPU as a result of polling while in a background tab seems like it should almost always be a bad thing to do.  Lots of platforms change scheduling policies for background apps (eg. all mobile devices are much stricter than this) and users are clamoring for improved battery life.  We should absolutely continue to tweak the thresholds and heuristics here (learning from experience), but we shouldn't let fear or philosophical arguments keep us from trying to be aggressive at improving the user experience of the web.

[Elliott Sprehn]

On Tue, Jan 24, 2017 at 2:21 PM, Rick Byers <rby...@chromium.org> wrote:

Alexander, can you please clarify a couple points about the design (I think there's some confusion on this thread):

1. It's only timers (i.e. application polling) that are throttled, right?  Eg. in the case of an active websocket (or other network connection) when a network response is received, it's still given to the application immediately as normal.
   
   
2. If a user (eg. for the trading app discussed here) really wants to allow the tab to do expensive timer-based polling, they can always drag that tab out into it's own window.  It will then be considered a "foreground" tab and will not have any throttling applied.  That's certainly the behavior I'm seeing on your demo page.

That's only true if the window is visible or your OS doesn't support occlusion reporting for windows.

[lightlyfluf...@gmail.com]

I've just read through the entire thread and I have a small question/thought. I'm just a user, not a developer.

It may be interesting to do some real-world testing against the high-load platforms you briefly refer to in the summary paragraph, and try and figure out how much latency is introduced for those specific cases.

I say this because some platforms simply don't care about UX and performance and are only focused on impressions and clicks at the cost of all else, and this new behavior may inhibit the ability of an ad in a background page to pull in new content, or (possibly more likely) slow down analytics scripts' ability to collect metrics; and since this behavior is entirely heuristic and can be killed by simply playing silent audio or using a WebSocket connection, I wouldn't put it past some to simply just do that to keep things working "properly."

I'm sure this has probably already been considered, but I do wonder.

[fer...@gmail.com]

Can you clarify how the new throttling behavior affects active WebRTC connections in background tabs? I maintain WebTorrent (https://webtorrent.io), which maintains numerous WebRTC data channel connections to download/upload data to/from a P2P network. Users often intentionally keep tabs open in the background to share files from sites like https://file.pizza and https://instant.io. Will 'message' events from WebSockets and WebRTC data channels continue to be processed normally – and will we be able to create new WebRTC connections while we're backgrounded?

If this change literally only affects setTimeout and setInterval, then I think our applications will be okay.

[da...@adblockplus.org]

On Friday, January 20, 2017 at 10:41:49 PM UTC+7, Alexander Timin wrote:

To respond to your concerns we will be limiting maximal throttling delay to 30 seconds effective now. Also we will be looking into disabling aggressive background throttling for webpages with active (e.g. websockets) connections.

Advertisers commonly misuse WebSockets as a way to circumvent ad blockers, be careful adding an exception for pages that use them. (See #129353.)

On Wednesday, January 25, 2017 at 8:46:47 AM UTC+7, lightlyfluf...@gmail.com wrote:

... and since this behavior is entirely heuristic and can be killed by simply playing silent audio or using a WebSocket connection, I wouldn't put it past some to simply just do that to keep things working "properly."

Yes, I think this is true. Having worked to stop the circumvention of ad blockers for a while we see browser APIs abused in every possible way. After all a lot of money is at stake. Do you think they'll think twice about using a nasty hack if it helps them make more money?

[sergio...@workwave.com]

This will very likely break or cause issues to webapps relying on websockets, needing to keep them alive and needing to do intensive background processing on incoming data (including updating the screen in background to avoid flashing effects when switching tabs).

While this may not affect the majority of B2C sites and webapps, it will impact more complex B2B desktop webapps, and that impact may be underestimated by the blink team because of the paid nature of such apps.

The company I work for for sure has more than one webapp that will be negatively impacted by this change.

So while the goal is noble and I agree that ServiceWorkers are the way to go they are still not widely supported (http://caniuse.com/#feat=serviceworkers) so they are not an option today.

Because of the high-impact of this change please consider one or more of the following:

- relax or entirely remove throttling if a webpage has active websocket connections

- disable strict throttling if running on a desktop and especially if not running on battery power (no need to save battery if battery is not being used anyway)

- give the user the option of disabling strict throttling in "site settings", possibly by asking him/her when the browser detects an "excessive" amount of background work (just like permission is asked when the browser detects JS code querying for the GPS position)

Thanks!

[dave....@help.com]

I could understand this recommendation if service workers were something that we could use instead of websockets however, that's not the case: http://caniuse.com/#feat=serviceworkers

We build customer service software that updates in realtime, often in background tabs (live chat, help desk). This change means we now need to support 2 infrastructures for pushing updates to our customers websockets and service workers. We have no problem with doing this work over time but without broad adoption of Servie Workers, your timeline seems incredibly aggressive. Please consider the engineering costs associated with quality businesses who rely on websockets in the background for their applications.

[Rick Byers]

Folks, nothing in this design says that it throttles WebSockets activity.  We're still waiting for Alexander to confirm, but as far as I'm aware there is no reason that any of these cases of background network activity will be impacted in any way.  The only impact should be to things which are polling via setTimeout/setInterval AND consume a lot of CPU when doing so.  Timers are already specified to be delay AT LEAST (step 14) the specified time, but OFTEN wait longer in all browsers so this is not something that's fundamentally new, just a tweak to existing timer throttling heuristics.

Rather than speculate about potential issues (which we have no reason to believe are really an issue in practice), PLEASE try out test cases against Chrome beta and file concrete bugs if you see failures for cases you feel are legitimate.  We are NOT going to make any design changes here based on speculation.  This design has been shipping in Chrome beta and other channels / field trials before that for quite some time and has gotten a lot of testing against real-world sites.  We currently have no reason to believe that there is non-trivial negative impact to existing sites, and we have lots of data showing significant positive benefits to the user experience.

Thanks,

   Rick

[Alexander Timin]

Unfortunately, our current implementation throttles WebSockets. Because of this we ARE NOT SHIPPING this intervention in M56.

The current plan is to disable time-budget background timer throttling for the pages with active connection (websocket, webrtc and server-sent events) and to ship in M57 (subject to further feedback).

We will keep you updated with the progress.

[Dave Koston]

Thanks for the update and your response to the communities’ concerns!

[jel...@gmail.com]

It seems like the net effect of this will be that unscrupulous devs will play silent audio all the time to hog resources, resulting in their apps appearing to perform better than those of well-behaved devs. This doesn't seem like a very good idea.

[Michał Gołębiowski]

Please make sure that when you introduce such throttling there's always a command line flag to disable it. Otherwise it's a nightmare for developers as running a simple Karma test suite in Chrome in watch mode is going to fail all the time once the Chrome window goes in the background.

This has been a problem in the past, it led to a creation of the --disable-background-timer-throttling flag. But even with this flag Chrome is *still* throttling something on macOS and some of my colleagues are unable to test on Chrome locally because of this issue.

[Peter Kasting]

On Wed, Jan 25, 2017 at 5:09 PM, Michał Gołębiowski <m.g...@gmail.com> wrote:

Please make sure that when you introduce such throttling there's always a command line flag to disable it. Otherwise it's a nightmare for developers as running a simple Karma test suite in Chrome in watch mode is going to fail all the time once the Chrome window goes in the background.

This has been a problem in the past, it led to a creation of the --disable-background-timer-throttling flag. But even with this flag Chrome is *still* throttling something on macOS and some of my colleagues are unable to test on Chrome locally because of this issue.

While I don't make the final call on any of this stuff (I'm not a web developer or Blink developer, I'm just Chrome's unofficial command-line flag wrangler), I would say that any case where a developer needs to disable throttling to get their work done is a case we should understand and have a better solution for than a command-line flag.

For example, we should make sure we understand what Karma needs and whether it can move to ServiceWorker on Chromium, we should know about other cases where devs are blocked by this, etc.

It's OK to ship flags in the short-term, but not as long-term solutions for categories of problems.  In the limit, if there is absolutely no other way to solve problems than by giving developers a switch, then that switch needs to appear in the Chrome dev tools or options, not as a flag.

PK

[Alexander Timin]

Silent audio will not grant an exception from throttling. Throttling mechanism uses the same source of information as tab audio icon, so user will see this and if the page is muted, exception will be revoked and page will be throttled.

[Michał Gołębiowski]

It's OK to ship flags in the short-term, but not as long-term solutions for categories of problems.  In the limit, if there is absolutely no other way to solve problems than by giving developers a switch, then that switch needs to appear in the Chrome dev tools or options, not as a flag.

Any option needed by Karma needs to either work by default or be a command line flag. Options toggled manually in settings are not an option as Karma creates a new Chrome profile on every run and they are initialized with default options, of course.

--

Michał Gołębiowski

[felix...@gmail.com]

It would be nice to have a whitelist of domains that we can exclude this feature for.

I am thinking of a web game example specifically, like the idle game type.  But even oracle uses a web interface for items and i have helped develop a lot of analytic tools which might be impacted by this change. 

[shac...@gmail.com]

I'm wondering, does anyone have a minimal reproduction code for this issue/feature?
could be valuable for people to test it and check it in their environment

[dacraz...@gmail.com]

 It would be nice if we could hold off on this until the Service Worker adoption was higher in other browsers.  This leaves us in a place where Chrome is becoming like the old IE.. pushing specs faster than the other market adopts. 

I have recently found myself writing more 'chrome' specific hacks..  You don't want to become the next IE6..

[mathieu.ho...@gmail.com]

I would like to ask for an official exemption to the background timer throttling for any page that have an active local MediaStream.

This would allow for any web app that processes user media (whether audio, video or screen sharing) to do it regardless of how they transmit it (WebSocket, PeerConnection), if at all. For example, we may imagine applications that record the screen locally instead of streaming it. For this type of application, an exemption on active connection doesn't work.
Local media access is always behind a user permission, so the drive-by web would not be able to abuse this vector. Active access to devices is also clearly indicated in the UI, similarly to playing audio.
I purposely exclude remote MediaStream from this exemption request, since an abuser could open a connection to receive a dummy video stream to work around the throttling (once active WebRTC connections are removed from the exemptions).

Regards,

Mathieu Hofman

[warren....@gmail.com]

Is there any low level logging (via sawbuck) of a tab or page entering this throttled state to assist in debugging.

[Sami Kyostila]

This JavaScript console message gets logged the first time a task is deferred by this mechanism for more than 3 seconds:

https://cs.chromium.org/chromium/src/third_party/WebKit/Source/platform/scheduler/renderer/web_view_scheduler_impl.cc?rcl=a1a7d7c0a8ffdbbc321bf66055cb777e404563b0&l=367

- Sami

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Warren McDonald]

Hi Sami,

I have tried this with the JS Fiddle and I see it drop back to 5000 ms intervals when in the background which indicates around 4 sec delayed, but there is no console message. 

Warren

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

--

Warren McDonald

[Sami Kyostila]

+Alexander Timin 

Could you send a link to the test please?

- Sami

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

--

Warren McDonald

[bryan....@shopify.com]

I too am not seeing any console messages related to timers being delayed up to 1 minute when tab is backgrounded. Is there anything else I can look into for the automatic exceptions? Using the jsfiddle demo in the intent document, adding a second task or increasing the expensiveness of the tasks easily gets me up to 60s delay.

To unsubscribe from this group and stop receiving emails from it, send an email to blin...@chromium.org.

--

Warren McDonald

[Michaela Merz]

Here we go again. The background suspension and forced unloading on Android is already causing lots of troubles because chats and messages are not updated and we don't want to bother the users with audible push whenever a new chat message arrives. I understand the need to conserve energy and memory, but unless we are given the tools to keep in touch with our users even when a website or app is backgrounded, each an every method is just another mechanism to sever the connection between a web site and its users. If you think this is the correct method of furthering advanced web technology I have news for you: It isn't.

Michaela

On Friday, November 11, 2016 at 12:06:29 PM UTC-6, Alexander Timin wrote:

Contact emails

 

alt...@chromium.org

Design doc

Time-based renderer task throttlingbother the