You've mentioned things like mail/calendar should still work. Is this
because the expected background CPU usage is low or is it that it's
using some API that directly opts it out of the freezing behavior? I'm
particularly worried about things like calendar that don't _typically_
need to do any work, but _occasionally_ want to show a notification
that you have an upcoming meeting. If there happens to be some
background work happening in those that causes it to be frozen, that
seems like it could be a hard to discover problem (due to the fact
that it maybe only occasionally uses too much CPU) and quite painful
for the user. In general, any site that can do background work and
notifies the user via notifications seems like it could be problematic
Thanks,
Vlad
On Fri, Nov 29, 2024 at 7:38 PM Rick Byers <rby...@chromium.org> wrote:
LGTM1 to ship including a deprecation trial
On Fri, Nov 29, 2024, 5:00 p.m. François Doray <fdo...@google.com>
wrote:
On Friday, November 29, 2024 at 3:13:39 PM UTC-5 Rick Byers wrote:
tl;dr: Just one remaining question about providing a
developer opt-out (like a deprecation trial).
On Fri, Nov 29, 2024 at 12:25 PM Francois Pierre Doray
<fdo...@chromium.org> wrote:
Hi Rick,
Thanks for raising your concerns regarding
troubleshooting issues caused by Tab Freezing on
Energy Saver.
> Does Chrome have any visual indication that a tab
has been frozen?
There is no indication that a tab is frozen. However,
the feature only operates when Energy Saver is active,
signaled by a leaf icon next to the omnibox. When
Energy Saver is first activated or when the leaf icon
is clicked, a bubble indicates that "Background
activity and some visual effects may be limited".
Ah cool, I had never noticed that before myself. I see
there's also a prominent "turn off now" button:
image.png
That seems like a significant mitigation to me. If someone
is having trouble with some site it seems like there's a
decent chance that they (or their IT support people) would
notice this indicator, click it, then click "turn off now"
and confirm that fixes the issue. From there I'd imagine
troubleshooting would be pretty easy (google searches for
"chrome energy saver" would point to the per-site opt-out
etc.)
We avoided a frozen tab indicator because in the long
term (2-3 years), we plan to freeze most background
tabs, to ensure that they don't steal resources from
the foreground tab. At that point, there will be a
visual indication for tabs that are /not/ frozen (e.g.
playing audio = speaker icon, using the progress
notification API
<https://github.com/explainers-by-googlers/progress-notification> to
do arbitrary work = UI TBD).
I love that long-term plan, thanks! Personally I'd love to
have a mode where pages get to run in the background only
if they show such an icon or in response to me granting
their origin that permission. That's not behind a flag or
anything yet, right?
"Pages get to run in the background only if [they show some
UI]" : In 2-3 years, we'd like this to be the default
behavior, due to the expected foreground tab speed up and
battery savings. It's not yet behind a flag.
> How discoverable is it for users that they can add a
site to an exclusion list?
Users can add sites to the exclusion list via the
"Performance" tab in Chrome settings (direct link:
chrome://settings/performance), under "Always keep
these sites active." This is also mentioned in the
help article
<https://support.google.com/chrome/answer/12929150> (will
be updated for this launch).
Yeah I saw that, and I like that the UI contains a
"current sites" list rather than requiring copying URLs.
But that alone certainly is not discoverable for a user
who simply has a broken web page and doesn't know why. But
given that disabling energy saver is very discoverable,
that's good enough for me as long as this is coupled just
to energy saver. I guess you won't really have a way to
measure how much site compat issues lead users to disable
energy saver, eh? I imagine most users disabling it will
do so for the performance / visual quality concerns, not
site compat reasons.
We could run a HaTS survey to understand what leads users to
add sites to the exclusion list. Let me know what you think
and I can prioritize this.
It's not important for the launch process, so up to you. Not
needed from my perspective.
While discoverability is limited, most users won't
need this feature. Typical
mail/chat/calendar/phone/drive/music
streaming/videoconferencing/... apps will either not
exceed the CPU threshold for freezing or be opted out
via API usage. Sites requiring high background CPU
usage under Energy Saver (outside of audio/video
calls, device control...) can direct users to the
Chrome settings page or recommend using this policy
<https://chromeenterprise.google/intl/en_ca/policies/#TabDiscardingExceptions>
to
enterprise admins (policy doc will be updated for this
launch).
Yes I'm definitely convinced that "most" (probably even
>99.99%) of users won't have a problem - your design is
great for that, thank you! But what I've learned from my
incident post-mortem responsibilities is that it's the
~0.0001% of users that we have to really focus on to
reduce the risk of most OMGs. Ask Robert about why I'm
afraid of his wrath around this next time you see him in
the office :-).
Realistically I'd expect most such sites to just hack in
some API usage that tickles your heuristic (like take an
IndexedDB lock just for the purposes of being kept alive).
That 's going to be much more effective for them than
trying to direct users to take some manual steps, right?
That seems unfortunate to me, as it will make your life
harder in driving down the exceptions. Experience with
this sort of thing is a big part of the motivation behind
our guidance
<https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpSpNJ96U8trhNkfV0v9fk/edit?tab=t.0#heading=h.glc7fyugcipe>
for providing explicit developer opt-outs for breaking
changes (especially interventions like this). Sure, there
is some risk of an explicit opt-out being abused but that
risk isn't necessarily any greater than abuse of your
heuristic, and at least you can more easily measure and
track it and update behavior as necessary for any "arms
race" with abusive sites. Have you considered offering
developers a deprecation trial
<https://www.chromium.org/blink/launching-features/#deprecation-trial> to
reduce the risk of them abusing your heuristics and get
you contact info for the developers who feel they must
opt-out?
I hadn't considered a deprecation trial, but I think it's a
good idea to reduce the risk of Web developers abusing our
heuristics. In terms of process, should I create a "Feature
removal" entry at chromestatus.com <http://chromestatus.com>
or can we handle this as part of this intent?
Great! Yeah we can just use this intent, no need for extra
overhead. And of course it's important to document how to use the
trial in the blog post.
We think that requiring some effort to allow high
background CPU usage under Energy Saver is reasonable,
as it can significantly impact battery life and
contradicts Energy Saver's purpose (note: Energy Saver
is only available on battery power, activates when
battery level is below 20% by default).
I suspect that most impacted users would simply disable
energy saver completely rather than make the extra effort
to discover and use the site-specific opt-out. But that's
fine - both settings aren't hard to find, and if you see a
lot of users disabling energy saver then you can do some
research to see if better per-site controls might help
reduce that (though we might be stuck for the users who
have already opted out completely).
"though we might be stuck for the users who have already opted
out completely": If we observe any significant difference in
the number of Energy Saver activations between the
Control/Enabled groups, or if we observe an upward trend of
users without Energy Saver after the launch, we'll investigate
why and make adjustments.
Oh of course, that makes sense - thanks!
> Is the plan for Chrome 133 to be fully at 100%, with
132 still well below that?
The plan is to experiment on 1% of stable users in
Chrome 133 and then ramp up gradually as we gain
confidence that the feature is well tuned. The feature
is already under experimentation in Canary/Dev. We
intend to expand Tab Freezing beyond Energy Saver in
the future, taking into account lessons learned from
this limited scope launch, but that will be handled
under new Intents.
Ok, we've come to appreciate that that pattern increases
the risk somewhat because it makes it even harder for IT
admins and support personnel to reproduce and action site
compat issues their users are complaining about. I don't
think we've yet come up with some well-informed guidance
for mitigating this risk, so I won't ask for something
different (eg. could keep to <10% in 133 and then go 100%
in 134). But it's something to keep an eye out for in
customer reports and perhaps inform our future guidance,
so please let me know (here or privately) if it ends up
showing up as an issue in customer reports or not.
Sounds good.
> Will the blog post you mentioned be published prior
to 133 beta (Jan 15)?
That's the goal, though DevRel hasn't confirmed a
date. I'll check in with them.
Ok, thanks. If the blog post gets delayed, please hold off
on extending the experiment to stable until the blog post
is live.
Sounds good.
Have a nice day,
François
On Wednesday, November 27, 2024 at 10:20:09 AM UTC-5
Rick Byers wrote:
I evaluated this intent relative to our compat
principles <https://bit.ly/blink-compat> and
overall think you've done an excellent job
mitigating the compat risks. In particular the
user controls, developer-influencable heuristics
and enterprise opt-out seem likely to be
significant mitigations. I'm also confident that
you will be proactive in monitoring for issues and
being responsive to feedback.
Heuristics like the energy saver and CPU threshold
seem great to me on balance, but I'm also nervous
that they will make troubleshooting rare but
severe issues harder (especially since these
signals can't really be monitored via web page
telemetry). We've learned from one recent incident
that sometimes the rarest incidents can be
extremely bad - eg. causing a serious business
disruption for one single organization but not
more widely (making support for that organization
much harder). In such cases, discoverability and
understandability of the issue (including by
skilled IT support personnel) is key to avoiding
extended outages. With that in mind, I have a
couple questions:
Does Chrome have any visual indication that a tab
has been frozen? How discoverable is it for users
that they can add a site to an exclusion list?
Is the plan for Chrome 133 to be fully at 100%,
with 132 still well below that? I'm just wondering
to what extent someone looking into website logs
for an issue will be able to detect a clear
correlation with Chrome 133 (increasing the chance
that they reach out to us or find this mentioned
in the chrome 133 blog post)?
Will the blog post you mentioned be published
prior to 133 beta (Jan 15)? I see it's mentioned
<https://support.google.com/chrome/a/answer/7679408?hl=en&co=CHROME_ENTERPRISE._Product%3DChromeBrowser#top:~:text=131%20on%20Android-,Tab%20freezing%20on%20Energy%20saver,-When%20Energy%20saver>
in Chrome 131 enterprise release notes already,
thank you!
Thanks,
Rick
On Tue, Nov 26, 2024 at 3:11 PM Chromestatus
<ad...@cr-status.appspotmail.com> wrote:
Contact emails fdo...@chromium.org,
shas...@chromium.org
Explainer None
Specification
https://wicg.github.io/page-lifecycle
Design docs
https://docs.google.com/document/d/1uTJifh_erMX4_CTKgKljlj9O4SAmGam5W61FBHeasGI/edit?usp=sharing
Summary
When Energy Saver is active, Chrome will
freeze a "browsing context group" that has
been hidden and silent for >5 minutes if any
subgroup of same-origin frames within it
exceeds a CPU usage threshold, unless it: -
Provides audio- or video-conferencing
functionality (detected via microphone, camera
or screen/window/tab capture or an
RTCPeerConnection with an 'open'
RTCDataChannel or a 'live' MediaStreamTrack).
- Controls an external device (detected via
usage of Web USB, Web Bluetooth, Web HID or
Web Serial). - Holds a Web Lock or an
IndexedDB connection that blocks a version
update or a transaction on a different
connection. Freezing consists of pausing
execution. It is formally defined in the Page
Lifecycle API. The CPU usage threshold will be
calibrated to freeze approximately 10% of
background tabs when Energy Saver is active.
Blink component Blink>Scheduling
<https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EScheduling>
TAG review None
TAG review status Not applicable
Risks
Interoperability and Compatibility
Interoperability: This feature does not expose
new capabilities to the Web, so it has low
chances of creating situations in which the
same HTML/CSS/Js/... behaves differently in
different browsers. That being said, we invite
other browsers vendors that already shipped
"tab freezing" to share and discuss their
opt-out rules, which will help offer
consistent behavior for web developers across
browsers, avoiding situations where a site's
background functionality works correctly in
some browsers but not others. Compatibility:
This feature may affect existing sites with
background functionality. However, breaking
some functionality to extend battery life is
in line with user expectations when "Energy
Saver" is active. We're interested in Web
developer feedback to adjust our opt-outs and
minimize avoidable breakages. "Energy Saver"
can be disabled via the the
"BatterySaverModeAvailability" enterprise policy.
/Gecko/: Under consideration
(https://github.com/mozilla/standards-positions/issues/87)
/WebKit/: No signal
/Web developers/: No signals In the past, Web
developers expressed concerns about freezing,
because it made it difficult to implement
background functionality that users care about
in a reliable way (e.g. notification for
calendar event). By freezing only pages that
use a lot of CPU and only when Energy Saver is
active, breakages that were reported in the
past are mitigated. Additionally, we will
listen to Web developers feedback on multiple
channels (crbug, blink-dev, stack overflow,
twitter, github) and make adjustments to
heuristics if we find that background
functionality that users care about is broken.
Users may deactivate Energy Saver or manually
opt-out sites at chrome://settings/performance
/Other signals/: Chrome on Android freezes
background tabs after 5 minutes
(https://groups.google.com/a/chromium.org/g/blink-dev/c/NKtuFxLsKgo/m/brL3bfS5CAAJ).
Chrome on desktop and Android freezes pages
before putting them in the BFCache. Chrome on
desktop freezes tabs in collapsed tab groups.
Edge freezes background tabs after a
configurable timeout
(https://www.microsoft.com/en-us/edge/features/sleeping-tabs-at-work?form=MT00D8).
Ergonomics
No Ergonomics Risks identified.
Activation
No action is required to support browsers that
don't freeze pages.
Security
A frame can observe when it is frozen, either
directly (via the “freeze” event) or
indirectly (timer runs later than expected,
server doesn’t receive a ping…). When the
decision to freeze a frame depends on
observations made on other cross-origin frames
(crossing CPU usage threshold, using Web API
that opt-outs from freezing) there is a risk
of leaking information across origins.
Multiple solutions were considered to balance
security and ergonomy requirements. We finally
landed on "freezing a browsing context group
based on independent observations made on
groups of same-origin/same-page frames in that
browsing context group". Pros & cons + All
frames on a page are in the same “frozen”
state (does not break Web devs assumptions). +
All frames that can synchronously script each
other are in the same “frozen” state (does not
break Web devs assumptions). + Not aggregating
CPU usage across origins minimizes leaks,
because an attacker can’t vary its own CPU
usage to precisely measure the CPU usage of
another origin. - Leaks Web API usage across
cross-origin frames (a frame can learn that a
cross-origin frame in the "browsing context
group" uses or doesn't use one of the APIs
that prevents freezing depending on whether it
itself gets frozen).
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?
This is a desktop-only feature which does not
affect Webview.
Debuggability
The frozen state of a tab is displayed in the
"Lifecycle state" column of chrome://discards.
Whether a page can be frozen and why (e.g.
usage of WebRTC) is displayed in the "Is
freezable" column of chrome://discards. The
#freezing-on-energy-saver and
#freezing-on-energy-saver-testing features at
about:flags can be used to test this
intervention. It is also possible to manually
freeze a tab via chrome://discards to verify
how it reacts.
Will this feature be supported on all six
Blink platforms (Windows, Mac, Linux,
ChromeOS, Android, and Android WebView)? Yes
Chrome for Android already freezes pages in
the background (not tied to Energy Saver).
This proposal brings freezing to desktop.
Is this feature fully tested by
web-platform-tests
<https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?
No
Flag name on about://flags
freezing-on-energy-saver
Finch feature name FreezingOnBatterySaver
Requires code in //chrome? False
Tracking bug https://crbug.com/325954772
Launch bug
https://launch.corp.google.com/launch/4282880
Measurement This feature doesn't introduce new
APIs that web pages need to adopt.
Availability expectation This feature doesn't
introduce new APIs that other browsers need to
make available. It expands the sets of
conditions under which Chrome may freeze tabs
(previously, only tabs in collapsed tab groups
could be frozen).
Adoption expectation This feature doesn't
introduce new APIs that web pages need to
adopt. Web pages may listen to the
freeze/resume events to react to freezing, but
it's not an issue if a web page doesn't. These
events are already dispatched when a tab in a
collapsed tab group is frozen.
Adoption plan In collaboration with DevRel, we
will publish an article covering the
conditions under which freezing is triggered
and possible remediations for broken
background use cases.
Non-OSS dependencies
Does the feature depend on any code or APIs
outside the Chromium open source repository
and its open-source dependencies to function?
No
Estimated milestones Shipping on desktop 133
DevTrial on desktop 132
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).
This feature does not modify the spec. It
changes the conditions under which tabs are
frozen in Chrome. Those conditions are
expected to evolve over time.
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5158599457767424?gate=5076873410772992
Links to previous Intent discussions Intent to
Prototype:
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAG9b2qVcRLRWXUz61AkRWi%2BkaOJwgUK8bNCRBG6LOpqgOd%2BvSw%40mail.gmail.com
Ready for Trial:
https://groups.google.com/a/chromium.org/g/blink-dev/c/Xu1C7WhoGm4/m/_9U_kLHDAwAJ
This intent message was generated by Chrome
Platform Status <https://chromestatus.com>.
--
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.
To view this discussion visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/67462b62.2b0a0220.19a388.0546.GAE%40google.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/67462b62.2b0a0220.19a388.0546.GAE%40google.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 visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY9fhohUewpp%3D_eeMcWEbQtZvBvLDNnnPT6eSAbdwxq8uA%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY9fhohUewpp%3D_eeMcWEbQtZvBvLDNnnPT6eSAbdwxq8uA%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 visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2P1o1wBfdum060TnNmotmxoCFr0fEqKjjzUg%2BaepNijkw%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2P1o1wBfdum060TnNmotmxoCFr0fEqKjjzUg%2BaepNijkw%40mail.gmail.com?utm_medium=email&utm_source=footer>.
