The network service needs access to the permissions policy. Previous CLs
moved all the dependencies so it is now safe to move this class.
The following files need to include permissions_policy.h because
otherwise they want to have access into incomplete `PermissionsPolicy`:
* components/permissions/permission_uma_util.cc
* third_party/blink/common/manifest/manifest_util.cc
* third_party/blink/renderer/core/html/client_hints_util.cc
* third_party/blink/renderer/modules/payments/payment_app_service_worker_registration.cc
* third_party/blink/renderer/modules/payments/payment_instruments.cc
Bug: 382291442
Low-Coverage-Reason: LARGE_SCALE_REFACTOR
Change-Id: Ifcf52df3bc5c035e8f6a45df02cf93f304b748c9
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6310821
Auto-Submit: Sandor «Alex» Major <sandormajor@chromium.org>
Owners-Override: Rick Byers <rbyers@chromium.org>
Commit-Queue: Sandor «Alex» Major <sandormajor@chromium.org>
Reviewed-by: Ari Chivukula <arichiv@chromium.org>
Reviewed-by: Rick Byers <rbyers@chromium.org>
Reviewed-by: Maks Orlovich <morlovich@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1426391}
This CL intends to tidy up the code by removing `is_javascript_enabled`
plumbing to ClientHints impl. The CH currently just refuses to add the
Client Hints headers if Javascript is disabled. This CL modifies to that
the check is done in the caller side.
Bug: None
Change-Id: Icf8b737871325b766c8edf8035e6dd961310de4e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6232361
Commit-Queue: Kouhei Ueno <kouhei@chromium.org>
Reviewed-by: Hiroki Nakagawa <nhiroki@chromium.org>
Reviewed-by: Rakina Zata Amni <rakina@chromium.org>
Reviewed-by: Ari Chivukula <arichiv@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1416653}
RFHI's permissions_policy() and GetPermissionsPolicy() are doing the
same thing, keeping the latter as that's exposed on the RFH as well.
Bug: 382291442
Change-Id: I846764815f6adb72c6906c59d6d6810e02a5d611
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6164805
Reviewed-by: Bo Liu <boliu@chromium.org>
Commit-Queue: Sandor «Alex» Major <sandormajor@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1404447}
`spanify` wants to rewrite this constant but fails to find the size.
This CL does so manually.
While we're at it, clean up a number of `DCHECK()`s that use only
compile-time constants, deduplicating them, upgrading them to
`static_assert()`, and moving them right under the declaration of
`kWebEffectiveConnectionTypeMapping`.
Additionally, remove a legacy `DCHECK()` from
`network_state_notifier.cc`, since converting this constant to a
`std::array` also gives us bound checks, which will surface a crash just
as reliably as said `DCHECK()`.
Bug: 364338808
Change-Id: I8ae7ca4f70045f397cb41179a264e0f15413348c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6023055
Reviewed-by: Kinuko Yasuda <kinuko@chromium.org>
Commit-Queue: Kalvin Lee <kdlee@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1384245}
The Accessibility Page Zoom feature has shipped to 100% Stable in the
last milestone. This CL safely removes all references and checks
against the flag, since they are no longer needed.
The feature shipped with a FeatureParam set to false. We could remove
a method and all related checks, but instead we have kept that method
and the related tests around, since there may be future work to
experiment with modifying this param. We added some ForTesting methods
to make this all work since we are no longer initializing tests with
specific flag and param values.
Note: This CL will be making the FontSizePrefs flow obsolete, but that
will be removed in a follow-up CL to keep the CLs easier to review.
AX-Relnotes: N/A
Bug: 376038818
Change-Id: I7b75c6d235028602000af64cab4ff0f0bfe087c9
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5970817
Reviewed-by: Ted Choc <tedchoc@chromium.org>
Code-Coverage: findit-for-me@appspot.gserviceaccount.com <findit-for-me@appspot.gserviceaccount.com>
Reviewed-by: Philip Rogers <pdr@chromium.org>
Reviewed-by: Amanda Lin Dietz <aldietz@google.com>
Reviewed-by: Theresa Sullivan <twellington@chromium.org>
Reviewed-by: Rakina Zata Amni <rakina@chromium.org>
Commit-Queue: Mark Schillaci <mschillaci@google.com>
Cr-Commit-Position: refs/heads/main@{#1376444}
Previously, "page zoom" was overloaded to refer to (1) the browser zoom
user setting and (2) the actual multiplier used in rendering arithmetic.
The first value uses a log scale and doesn't include hardware device
pixel ratio; the second value is a straight multiplier and *does*
include device pixel ratio. Some parts of the code distinguished between
these two values by referring to "(page) zoom level" for the first
value and "(page) zoom factor" for the second.
A subsequent change will add a third variable to the mix: the CSS "zoom"
property, which for the first time will affect the rendering of an
<iframe>'s content document. Browser zoom and inherited CSS zoom will
combine to produce a single "zoom level" value using the log scale;
"zoom level" will be de-log-ified and multiplied by device pixel ratio
to give a "zoom factor" used for rendering. Importantly, "zoom level"
and "zoom factor" are no longer page-level concepts; the new behavior
of CSS zoom means that two frames in the same page may have different
zoom levels and different zoom factors.
This CL attempts to bring consistent naming conventions to all
zoom-related code. In particular, the use of "page" in zoom-related
names is mostly eliminated, in favor of "browser zoom level" to describe
the browser zoom user setting and "layout zoom factor" to describe the
value used for rendering. The new naming convention can be seen most
clearly in the changes to local_frame.h and page_zoom.(h|cc).
Bug: chromium:329482480
Change-Id: I41abb9fd949f63f291487af9039391a4acc21cbc
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5621488
Reviewed-by: Philip Rogers <pdr@chromium.org>
Reviewed-by: Arthur Sonzogni <arthursonzogni@chromium.org>
Reviewed-by: Filipa Senra <fsenra@google.com>
Reviewed-by: Ted Choc <tedchoc@chromium.org>
Code-Coverage: findit-for-me@appspot.gserviceaccount.com <findit-for-me@appspot.gserviceaccount.com>
Reviewed-by: Devlin Cronin <rdevlin.cronin@chromium.org>
Reviewed-by: Emily Shack <emshack@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Reviewed-by: Khalid Peer <khalidpeer@chromium.org>
Commit-Queue: Stefan Zager <szager@chromium.org>
Reviewed-by: Danil Somsikov <dsv@chromium.org>
Reviewed-by: danakj <danakj@chromium.org>
Reviewed-by: Denis Kuznetsov <antrim@chromium.org>
Reviewed-by: Wez <wez@chromium.org>
Reviewed-by: David Roger <droger@chromium.org>
Reviewed-by: Kevin Graney <kmg@google.com>
Cr-Commit-Position: refs/heads/main@{#1314855}
Suppress unsafe buffer usage on a file-by-file basis. Out of
approximately 5850 .cc and .h files only roughly 160 files fail
compilation with the unsafe buffers warning.
Suppress only, by inserting boilerplate into affected files. Do not
re-write any code to work around the issues. Properly fixing each file
will be done in follow-up CLs.
//content/ is not removed from unsafe_bufers_paths.txt file and will be
also done as a follow-up, so it makes potential reverts simpler.
Bug: 342213636
Change-Id: I4a936e63dea95a78951f7bfae6d5487708ae3c0b
AX-Relnotes: n/a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5608913
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Owners-Override: Daniel Cheng <dcheng@chromium.org>
Commit-Queue: Nasko Oskov <nasko@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1312393}
The canonical bug format is TODO(crbug.com/<id>). TODOs of the
following forms will all be migrated to the new format:
- TODO(crbug.com/<old id>)
- TODO(https://crbug.com/<old id>)
- TODO(crbug/<old id>)
- TODO(crbug/monorail/<old id>)
- TODO(<old id>)
- TODO(issues.chromium.org/<old id>)
- TODO(https://issues.chromium.org/<old id>)
- TODO(https://issues.chromium.org/u/1/issues/<old id>)
- TODO(bugs.chromium.org/<old id>)
Bug id mapping is sourced from go/chrome-on-buganizer-prod-issues.
See go/crbug-todo-migration for details.
#crbug-todo-migration
Bug: b/321899722
Change-Id: Iee14d10d544e9f0ec046117cc4ec8a55c427adc0
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5469947
Reviewed-by: Darryl James <dljames@chromium.org>
Owners-Override: Alison Gale <agale@chromium.org>
Commit-Queue: Alison Gale <agale@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1290838}
The canonical bug format is TODO(crbug.com/<id>). TODOs of the
following forms will all be migrated to the new format:
- TODO(crbug.com/<old id>)
- TODO(https://crbug.com/<old id>)
- TODO(crbug/<old id>)
- TODO(crbug/monorail/<old id>)
- TODO(<old id>)
- TODO(issues.chromium.org/<old id>)
- TODO(https://issues.chromium.org/<old id>)
- TODO(https://issues.chromium.org/u/1/issues/<old id>)
- TODO(bugs.chromium.org/<old id>)
Bug id mapping is sourced from go/chrome-on-buganizer-prod-issues.
See go/crbug-todo-migration for details.
#crbug-todo-migration
Bug: b/321899722
Change-Id: Iabdfea2fd5393d6bbc54390ca0c995eb2c55bbaa
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5469882
Reviewed-by: Darryl James <dljames@chromium.org>
Owners-Override: Alison Gale <agale@chromium.org>
Commit-Queue: Alison Gale <agale@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1290673}
The canonical bug format is TODO(crbug.com/<id>). TODOs of the
following forms will all be migrated to the new format:
- TODO(crbug.com/<old id>)
- TODO(https://crbug.com/<old id>)
- TODO(crbug/<old id>)
- TODO(crbug/monorail/<old id>)
- TODO(<old id>)
- TODO(issues.chromium.org/<old id>)
- TODO(https://issues.chromium.org/<old id>)
- TODO(https://issues.chromium.org/u/1/issues/<old id>)
- TODO(bugs.chromium.org/<old id>)
Bug id mapping is sourced from go/chrome-on-buganizer-prod-issues.
See go/crbug-todo-migration for details.
#crbug-todo-migration
Bug: b/321899722
Change-Id: Ieeb461e2d489e86fd50b87a2a0721a2be34520c3
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5467317
Owners-Override: Alison Gale <agale@chromium.org>
Commit-Queue: Darryl James <dljames@chromium.org>
Commit-Queue: Alison Gale <agale@chromium.org>
Reviewed-by: Darryl James <dljames@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1290198}
Remove `defer` from
`URLLoaderThrottle::BeforeWillProcessResponse` and
`URLLoaderThrottle::BeforeWillRedirectRequest`
as they are not used.
This removes `DEFERRED_BEFORE_RESPONSE` as well.
Remove `URLLoaderThrottle::Delegate::RestartWithURLResetAndFlags`,
and instead signal a restart by setting `RestartWithURLReset` to true
in `BeforeWillProcessResponse` or `BeforeWillRedirectRequest`,
because and to clarify `RestartWithURLReset` can be set only
synchronously within these methods.
Remove `pending_restart_flags_`.
(`RestartWithURLResetAndFlags()` was always called with 0)
Remove `throttle_will_start_original_url_`
(always true when `RestartWithURLResetNow()` is called)
Remove `has_pending_restart_`, and use `RestartWithURLReset` local
variables instead, because Before* methods can no longer defer the
loading and thus restarting is processed immediately.
Bug: 325314722
Change-Id: Ia520d055966d03a2cb402f961afd837b74683796
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5149865
Reviewed-by: Kouhei Ueno <kouhei@chromium.org>
Reviewed-by: Hiroki Nakagawa <nhiroki@chromium.org>
Reviewed-by: Lingqi Chi <lingqi@chromium.org>
Reviewed-by: Arthur Sonzogni <arthursonzogni@chromium.org>
Commit-Queue: Hiroshige Hayashizaki <hiroshige@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1263152}
For fenced frames with unpartitioned data access, they will need to use
Shared Storage in order to read and write the unpartitioned data. They
will also need to be able to call the Private Aggregation API in order
to send reports and telemetry without running the risk of introducing a
fingerprinting vector. Both of those features are permissions
policy-backed features.
Fenced frames do not currently support permissions policies, so none of
these features will be able to be enabled. The reason we disabled
permissions policies originally was to prevent cross-channel
communication from the embedder into the fenced frame. However, fenced
frames with unpartitioned data do allow for data inflow, just not data
outflow. Because of that, we can now allow permissions policies to be
enabled on non-opaque fenced frames (i.e. fenced frames not created
using Protected Audience or Shared Storage).
This CL allows fenced frames to set and inherit permissions policies.
Only Shared Storage and Private Aggregation can be turned on. All other
permissions policies will be forced off if attempted to be enabled or
inherited, and a console warning will be output for debugging purposes.
Note that fenced frames created through Protected Audience or Shared
Storage will continue to have their existing restrictions, and this CL
will not affect their behavior.
As a feature of its architecture, MPArch does not have access to
permissions policy information in its parent on the renderer side. To
give a fenced frame that access, we need to explicitly give it that
information through the fenced frame properties. This CL adds the parent
frame's parsed permissions policies and its origin to the
FencedFrameConfig and FencedFrameProperties objects. This is done
instead of just adding the PermissionsPolicy object for IPC reasons. The
parsed permissions policies and origin can be sent in an IPC message and
are the 2 pieces needed in order to reconstruct a PermissionsPolicy on
the renderer-side.
This CL also fixes an issue where container policies for fenced frame
roots were not taken into consideration when building the permissions
policy on the renderer side.
This CL explicitly does not modify any permissions policy code related
to client hints. That will be done as a follow up if and when we choose
to allow client hints in fenced frames.
Change-Id: I00e56dc35e07e7dfa16a3b57eb40be384faa8252
Bug: 1515327
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5150117
Commit-Queue: Liam Brady <lbrady@google.com>
Reviewed-by: Dominic Farolino <dom@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1245934}
properties getter implementations.
See the comment of the added test
"GetFencedFramePropertiesShouldTravseFrameTree" in
fenced_frame_browsertest.cc for a detailed explanation of the crash.
The TLDR is the FencedFrameProperties used at browser side v.s.
renderer side are different. They may end up with different result in
some cases. For example, to reproduce, see below 3 layers of nested
frames, from top to bottom:
- Fenced frame.
- Urn iframe.
- iframe.
At browser, the iframe's navigation request gets the fenced frame's
FencedFrameProperties. Because at browser side the getter does not do
a tree traversal.
At renderer, during reportEvent call, the iframe gets the urn iframe's
FencedFrameProperties. Because at renderer side the getter does a tree
traversal.
The correct semantics here should be doing a tree traversal. The reason
is in this case an urn iframe should acting as if it is a fenced frame.
The CL
1. changed `FrameTreeNode::GetFencedFrameProperties()` to do tree
traversal by default, except for partition nonce. In a FF frame tree,
all frames should operate on the root FF's partition nonce.
2. made sure browser and renderer side calls for the getter both do a
tree traversal to fix this crash.
Also added test cases to verify the change does not regress partition nonce:
1. An urn iframe nested in a fenced frame should operate on the fenced
frame's partition nonce.
2. In the above test, if there is an additional regular iframe nested
under the urn iframe, it should also operate on the fenced frame's
partition nonce.
For ClientHintsExtendedData and permission policy related usage of
FencedFrameProperties getter, both call sites are calling the getter
inside after checking the node is a fenced frame root node. In this
case it has no difference whether to do a tree traversal or not. The
FencedFrameProperties of the fenced frame node itself is returned.
Plus client hints are disabled for now. Added TODO that future tests
should cover cases similar to above.
In long term, urn iframe support will be deprecated. This will make
the algorithm much simpler. This parameter to the getter can be
removed entirely then.
Bug: 1470634
Change-Id: Ibdc56dd8263a1cee129afd14631113ec4b9f556d
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4775457
Reviewed-by: Rakina Zata Amni <rakina@chromium.org>
Commit-Queue: Xiaochen Zhou <xiaochenzh@chromium.org>
Reviewed-by: Garrett Tanzer <gtanzer@chromium.org>
Reviewed-by: Liam Brady <lbrady@google.com>
Cr-Commit-Position: refs/heads/main@{#1196205}
There are two headers to declare features in content.
- the public one: `content/public/common/content_features.h`
- the private one: `content/common/features.h`.
Unfortunately, most are declared in the public one, despite being used
privately exclusively. This violate the `content/public/` rules. This
patches provides a fix.
Parts of this patch was made programmatically using this script:
https://paste.googleplex.com/6699322946093056, with the following
output: https://paste.googleplex.com/5591288895242240
This patch:
1. Update `docs/how_to_add_your_feature_flag.md` to incentive
developers to the non public versions.
2. Move ~70 features back into the private version.
3. Programmatically update the includes to include the correct
#include header(s).
4. For consistency and minimizing the amount of files modified,
the two headers to use the `features::` namespace.
AX-Relnotes: n/a.
Change-Id: Id9126a95dfbc533d4778b188b659b5acc9b3d9e3
Bug: None
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4836057
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Commit-Queue: Arthur Sonzogni <arthursonzogni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1194718}
In order to enabled the UA Reduction/Deprecation origin trial for embed requests (both first-party and third-party), we introduced two client hints: Sec-CH-UA-Reduced/Sec-CH-UA-Full. We accomplished this by persisting Sec-CH-UA-Reduced/Sec-CH-UA-Full from an embed response headers if a valid Origin Trial token is present.
As we completed the UA reduction origin trials, Sec-CH-UA-Reduced and Sec-CH-UA-Full are no longer be persisted in any context, they should be removed and be simplified. For all future similar origin trials, we prefer to use Persistent Origin Trials.
This CL remove the two origin trial client hints: Sec-CH-UA-Reduced and Sec-CH-UA-Full and simplify the client hints logics when parsing
ACCEPT-CH headers. It also refactors corresponding tests to make the user-agent reduction behavior depending on the UA reduction phases' features.
The following up cls will:
* Remove UA reduction origin trial for service worker
* Remove UA reduction origin trial for all requests
Change-Id: I474122a36ec633d5589e8dfc5f11f31916a40863
Bug: 1258063
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4551662
Reviewed-by: Ari Chivukula <arichiv@chromium.org>
Reviewed-by: Bo Liu <boliu@chromium.org>
Reviewed-by: Colin Blundell <blundell@chromium.org>
Commit-Queue: Victor Tan <victortan@chromium.org>
Reviewed-by: Arthur Sonzogni <arthursonzogni@chromium.org>
Reviewed-by: Luc Nguyen <lucnguyen@google.com>
Reviewed-by: Yoav Weiss <yoavweiss@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1154936}
This is a follow-up of a review comment on crrev.com/c/4570158. For code
simplification, this CL does...
- rename PrerenderHost::GetPrerenderHostFromFrameTreeNode() to
GetFromFrameTreeNodeIfPrerendering(). This function is similar to
GetFromFrameTreeNode(), but it returns nullptr if a given
FrameTreeNode is not being prerendered.
- let GetFromFrameTreeNodeIfPrerendering() return a valid PrerenderHost
even when prerendering has already been canceled as long as its
FrameTreeNode is accessible.
Bug: 1355279
Change-Id: I6a1fc2b0e92d2a1d82f93b02ee5316a2c6929181
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4583320
Reviewed-by: Yoav Weiss <yoavweiss@chromium.org>
Reviewed-by: Lingqi Chi <lingqi@chromium.org>
Commit-Queue: Hiroki Nakagawa <nhiroki@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1154289}
When getting the viewport size of a subframe for client hints, the
DCHECK in RenderWidgetHostViewChildFrame::GetVisibleViewportSize() would
be triggered. This CL fixes that by always calling GetMainFrame() first
before getting the RenderWidgetHostView.
Bug: 1430329
Change-Id: I924f1594d2faa3d51b5db5f28fd678ef1ae2e219
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4559151
Reviewed-by: Ari Chivukula <arichiv@chromium.org>
Commit-Queue: Max Curran <curranmax@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1149254}
While writing the fenced frame spec for permissions policy interaction,
we decided to change the behavior to only allow a fenced frame to load
if the required permissions to load was enabled for *all* origins,
instead of just if the permissions were enabled for the origin of the
document being loaded into a fenced frame. This makes the spec simpler
and eliminates a weird corner case where a fenced frame could fail
when trying to navigate itself to a different origin, causing the ad to
break.
This CL reflects those changes in the implementation.
As part of this change, fenced frames created through an API that
navigate themselves to a cross-origin page need to know what the list of
required permissions was in the config. Currently, the redacted config
is not given to document that is cross-origin to the config's mapped
url. This CL modifies the behavior to give cross-origin documents access
to the config to calculate their permissions policies, but in a way that
prevents them from accessing the window.fence APIs. This does that by
introducing a new `VisibilityToContent`, `kTransparentForAllOrigins`,
which allows both same-origin and cross-origin documents to see a given
field. The existing `kTransparent` visibility will now only make fields
transparent if the document is same-origin to the mapped url.
Change-Id: I00acb013076d527e482b3ce8f4bd0e45a93c5cf8
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4514455
Reviewed-by: Dominic Farolino <dom@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Commit-Queue: Liam Brady <lbrady@google.com>
Reviewed-by: Arthur Sonzogni <arthursonzogni@chromium.org>
Reviewed-by: Garrett Tanzer <gtanzer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1148161}
As initial design, we only allow the main frame should parse accept-CH.
However, to support the one-off origin trial client hints
https://crrev.com/c/3179447, we allow to parse the origin trial client
hints in embedded frame. Also, we only support full update for the Accept-ch Cache to avoid the unnecessary prefs read.
When the embedded frame opt-in the user-agent reduction origin trial, it will try to do a full update to overwrite the existing main frame Accept-ch cache. This might cause problem to send client hints for embedded iframe subresource requests because the embedded iframe overwrite the existing accept-ch cache and the cache will only contains the origin trial client hints.
Instead of overwrite the accept-ch cache, we only allow to append the origin trial client hints to existing accept-ch cache. To avoid any performance regression, it only appends when embedded iframe response accept-ch header has origin trial hints and a valid origin trial token.
Change-Id: If985a5deb04a12209dd2124b4f347d83ab52c965
Bug: 1446805
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4547454
Commit-Queue: Victor Tan <victortan@chromium.org>
Reviewed-by: Ari Chivukula <arichiv@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1146582}
