Hi François,
We [MikeT, Rick, Yoav, Chris and I] discussed this on the API Owners
meeting and there were some things affecting user experience I was
concerned about.
Looking at the maximum perceived impact to the user, that would be that
the user is putting a tab in the background, but expecting some kind of
event in a couple of seconds. If that event depends on the throttled
timers, that event could, worst case, with this change be delayed from
10 seconds to 1 minute (or 10 seconds + 1 minute?). Before this change,
worst case would be that some event would be delayed from 5 minutes to 6
minutes.
I consider, from a usage perspective, a delay from 5 to 6 minutes (worst
case) acceptable if there are other benefits to the delay, but a change
from 10 seconds to 1 minute (worst case) seems much more impactful since
it would be fivefold increase in waiting time.
Considering that, have you investigated if there is some kind of middle
ground where a smaller change would get more or less the same benefit to
battery life? Or is there some other more advanced gradual throttling
that could make the worst case less bad? Or do you have data that shows
that my concern is irrelevant in some way?
/Daniel
On 2022-11-11 17:56, François Doray wrote:
We are experimenting on 1% stable since the beginning of October 2022
(M106+). We are also experimenting on 50% of Canary/Dev/Beta since
June 2022. Enabling on 100% of Canary/Dev/Beta for a few milestones
sgtm, if we think it will help identifying issues. So far, no bug
reports have been routed to me.
Note: Only timers with a "nesting level
<https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html#timer-nesting-level>"
greater than 5 are affected. A timer set from the visibilitychange
event handler, for example, won't be affected.
On Wed, Nov 9, 2022 at 12:02 PM Philip Jägenstedt
<foo...@chromium.org> wrote:
The potential compat risk of this seems significant, if it means
that pages can start misbehaving or breaking after 10 seconds in
the background, which seems common in workflows like logins or
ecommerce, where you might be flipping back and forth between tabs
to find passwords, confirm credit card transactions, etc.
Have there been any bug reports from the beta experiment yet? To
increase confidence, can we run this experiment at 100% on beta,
dev and canary for a few milestones before trying it on stable?
Are there any other ways we can gain insight on the compat risk?
On Tue, Nov 8, 2022 at 10:10 PM François Doray
<fdo...@chromium.org> wrote:
Contact emails
jiahe.zh...@intel.com, fdo...@chromium.org
Specification
https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html
Design docs
https://docs.google.com/document/d/1WFyfKUUxqM7uKxKOGhLiOjyY6T7QRduVcuHN0f6vJkk/edit
Summary
Enter Intensive Wake Up Throttling after 10 seconds if the
page is fully loaded when it becomes hidden. Currently, wake
ups from JS timers with a nesting level >= 5 are throttled to
1 per minute after the page has spent 5 minutes in the
background [1], which is very conservative and was chosen to
allow a launch of Intensive Wake Up Throttling with minimal
regression risk. We're now planning to reduce this timeout to
10 seconds if the page is fully loaded when hidden. [1]
https://chromestatus.com/feature/4718288976216064
Blink component
Blink>Scheduling
<https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EScheduling>
TAG review status
Not applicable
Risks
Interoperability and Compatibility
/Gecko/: No signal
/WebKit/: No signal
/Web developers/: No signals
/Other signals/: The more conservative version of Intensive
Wake Up Throttling shipped smoothly to 100% Stable more than 1
year ago. A few bugs were filed, but in all cases we've been
able to propose workarounds which made apps more efficient
(example
<https://bugs.chromium.org/p/chromium/issues/detail?id=1186569#c16>).
WebView application risks
Does this intent deprecate or change behavior of existing
APIs, such that it has potentially high risk for Android
WebView-based applications?
No, this feature will not ship on desktop platforms.
Debuggability
This is not a new Web Platform feature.
Will this feature be supported on all six Blink
platforms (Windows, Mac, Linux, Chrome OS, Android,
and Android WebView)?
No
This feature will only ship on desktop platforms. On Android,
the system severely limits resource consumption in background
renderers, which makes this feature unnecessary.
Is this feature fully tested by web-platform-tests
<https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?
Yes
Flag name
quick-intensive-throttling-after-loading
Requires code in //chrome?
False
Tracking bug
https://bugs.chromium.org/p/chromium/issues/detail?id=1324656
Estimated milestones
DevTrial on desktop
Enabled by default on desktop 104
109
Anticipated spec changes
Open questions about a feature may be a source of future web
compat or interop issues. Please list open issues (e.g. links
to known github issues in the project for the feature
specification) whose resolution may introduce web
compat/interop risk (e.g., changing to naming or structure of
the API in a non-backward-compatible way).
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5580139453743104
*Additional context*
*
*
The 1% stable experiment shows that this feature reduces
Chrome's CPU usage and extends battery life, as desired. We
plan to enable it by default in M109.
The 1% stable experiment is still ramping up, so we would like
to keep experimenting in M108, to get small confidence
intervals for all our metrics on all desktop platforms.
--
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+unsubscr...@chromium.org.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGD3t5EGWuOZgo1k5XExKpnjsRM9nacEeFMyiXkEOwW%3DkOqRUQ%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGD3t5EGWuOZgo1k5XExKpnjsRM9nacEeFMyiXkEOwW%3DkOqRUQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.
--
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+unsubscr...@chromium.org.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGD3t5Fy3FRsxTwde26%3DincDr7PR%2Bz4VKowfikMkPgSxxLhScA%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGD3t5Fy3FRsxTwde26%3DincDr7PR%2Bz4VKowfikMkPgSxxLhScA%40mail.gmail.com?utm_medium=email&utm_source=footer>.
--
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+unsubscr...@chromium.org.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5e54c5cf-72be-500f-c3d3-a1cf00514447%40gmail.com.
