In this change we are introducing logic to handle input events received
on Viz.
- Input events received on Viz before state transfer are queued.
- Upon receiving state transfer input events in queue for the given
sequence are flushed and forwarded to "correct"
RenderInputRouterSupportAndroid.
- Any out of order state transfer received are being ignored. This can
happen since the states can come over different pipes from different
web contents.
Bug: 370506271
Change-Id: I4c7aa7da0ccc17c4a9c52882e54686d491a743ed
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6073287
Reviewed-by: Peter Kasting <pkasting@chromium.org>
Reviewed-by: Aman Verma <amanvr@google.com>
Reviewed-by: Jinsuk Kim <jinsukkim@chromium.org>
Reviewed-by: Stephen Nusko <nuskos@chromium.org>
Reviewed-by: Jonathan Ross <jonross@chromium.org>
Commit-Queue: Kartar Singh <kartarsingh@google.com>
Cr-Commit-Position: refs/heads/main@{#1402336}
This reverts commit 30ffd2c53d.
Reason for revert: Suspected to break
All/RenderProcessHostTest.KillProcessZerosAudioStreams/Default
All/RenderProcessHostTest.KillProcessZerosAudioStreams/KeepAliveInBrowserMigration
on https://ci.chromium.org/ui/p/chromium/builders/ci/Linux%20TSan%20Tests/93486/overview
Original change's description:
> MediaSession: Add WebAudio players as ambient players
>
> When the AudioFocusManager ducks a MediaSessionImpl, it lowers the
> volume of its underlying players. This does not currently lower the
> volume of WebAudio playback, as AudioContexts are not registered to
> the MediaSessionImpl as media players.
>
> WebAudio has not been registered before as we have not wanted
> WebAudio playback to affect audio focus. However, there's an "ambient"
> audio focus type that accomplishes just that (currently unused by
> MediaSessionImpl). This CL adds "ambient" players to the
> MediaSessionImpl which will request ambient focus if there are no other
> players requesting a stronger type of audio focus, and makes
> AudioContexts register as ambient players. This allows the
> AudioFocusManager to know about WebAudio playback so it can force it
> to duck when needed.
>
> On the AudioContext side, it ducks the output volume by scaling the
> output audio bus according to the volume multiplier given by the
> browser side.
>
> Bug: 382316461
> Change-Id: Iffdb572d8c999177b35e17c76717460665bcfbbb
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6098352
> Reviewed-by: Hongchan Choi <hongchan@chromium.org>
> Commit-Queue: Tommy Steimel <steimel@chromium.org>
> Reviewed-by: Mark Foltz <mfoltz@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#1402262}
Bug: 382316461, 387915329
Change-Id: I55a57b64e544874b3973019640474846921b77dd
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6147027
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Owners-Override: Christian Dullweber <dullweber@chromium.org>
Auto-Submit: Christian Dullweber <dullweber@chromium.org>
Reviewed-by: Christian Dullweber <dullweber@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#1402279}
When the AudioFocusManager ducks a MediaSessionImpl, it lowers the
volume of its underlying players. This does not currently lower the
volume of WebAudio playback, as AudioContexts are not registered to
the MediaSessionImpl as media players.
WebAudio has not been registered before as we have not wanted
WebAudio playback to affect audio focus. However, there's an "ambient"
audio focus type that accomplishes just that (currently unused by
MediaSessionImpl). This CL adds "ambient" players to the
MediaSessionImpl which will request ambient focus if there are no other
players requesting a stronger type of audio focus, and makes
AudioContexts register as ambient players. This allows the
AudioFocusManager to know about WebAudio playback so it can force it
to duck when needed.
On the AudioContext side, it ducks the output volume by scaling the
output audio bus according to the volume multiplier given by the
browser side.
Bug: 382316461
Change-Id: Iffdb572d8c999177b35e17c76717460665bcfbbb
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6098352
Reviewed-by: Hongchan Choi <hongchan@chromium.org>
Commit-Queue: Tommy Steimel <steimel@chromium.org>
Reviewed-by: Mark Foltz <mfoltz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1402262}
Each ad in an interest group may have a list of
`selectableBuyerAndSellerReportingIds`, each a string. This implements a
potential Finch-configured limit on the number of elements in that list
that may be allowed. In actuality, this implements two separate limits,
a soft limit on interest groups being joined or updated, and a separate
hard limit on interest groups previously joined or updated that might
exceed the soft limit during a change in the limit. This allows for
potentially reducing that limit without invalidating any interest group
joined with the previous higher limit, by allowing the soft limit to be
reduced, waiting for all IGs joined with the previous limit to expire,
and only then reducing the hard limit to match the new soft limit.
Change-Id: Ib8855f85998517da9d5c6eee5e2bf8d056edcad4
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6139105
Reviewed-by: Maks Orlovich <morlovich@chromium.org>
Commit-Queue: Orr Bernstein <orrb@google.com>
Owners-Override: Orr Bernstein <orrb@google.com>
Cr-Commit-Position: refs/heads/main@{#1402025}
active_rfh_ should only be used in MaybeActiveRenderFrameHostChanged()
per code comments in the header file.
Also inlines the getter and rename it as |active_render_frame_host|.
Bug: N/A
Change-Id: Ibc57c8565c762be34cdf407fb570349e1925dcc5
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6143335
Commit-Queue: Wenyu Fu <wenyufu@chromium.org>
Reviewed-by: Charlie Reis <creis@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1401991}
This relands commit 60632268ea.
Difference to original: added support for AsDataPipeGetter and
extended blob-contenttype.any.js WPT to cover this case.
Original change's description:
> IDB: direct reads for blobs
>
> For the standard case of a page reading IDB data from the blob store,
> don't go through the blob registry on the i/o thread and instead
> connect the IDB bucket thread directly to the renderer.
>
> In some other (rarer) cases the blob registry is still used. This
> is accomplished by *additionally* registering a blob with
> BlobStorageContext using the same UUID, which is necessary for:
>
> * WriteBlobToFile(), which does lookup by UUID
> * loading data for a blob:// URL, i.e. mojom::Blob::Load, which is
> thunked through to the registry blob because implementation is non-
> trivial
>
> Bug: 373684390
> Change-Id: I9235f23303e4e6a05bf12a8acff32a5fb4e2a565
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6113789
> Commit-Queue: Evan Stade <estade@chromium.org>
> Reviewed-by: Steve Becker <stevebe@microsoft.com>
> Cr-Commit-Position: refs/heads/main@{#1400627}
Bug: 373684390
Change-Id: Ie555cf4b583b862d306c43e3e4be76e957ea6c5a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6138579
Reviewed-by: Steve Becker <stevebe@microsoft.com>
Commit-Queue: Evan Stade <estade@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1401872}
This should make metrics reporting more accurate, and allow
retry uploading if chrome shuts down before serialize_log_callback
finishes.
Change-Id: Id0413f166c35eb307730abce1788ca743c354c91
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6132289
Owners-Override: Gabriel Charette <gab@chromium.org>
Reviewed-by: Gabriel Charette <gab@chromium.org>
Commit-Queue: Gabriel Charette <gab@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1401799}
This metric records the number of `selectableBuyerAndSellerReportingIds`
on each ad. This is recorded once per ad for each ad in an interest group
at the point at which that interest group is joined, and once per ad for
each ad in an interest group that updates its ads as part of an interest
group update. This metric records the size of the
`selectableBuyerAndSellerReportingIds` field on each ad, even if
`selectableBuyerAndSellerReportingIds` is empty (size=0), but not
if the `selectableBuyerAndSellerReportingIds` field is omitted.
Bug: 356654297
Change-Id: Id01cf93eeca0dc83d66ff74f3c8c399315783784
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6126220
Reviewed-by: Maks Orlovich <morlovich@chromium.org>
Commit-Queue: Orr Bernstein <orrb@google.com>
Cr-Commit-Position: refs/heads/main@{#1401694}
The key system is passed from the render process which
cannot be trusted. Hence, handle invalid key systems
properly instead of NOTREACHED().
Fixed: 384549089
Change-Id: If5d61e2e8cbd2e02140308bf8d033a2bb0cd601b
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6137733
Reviewed-by: John Rummell <jrummell@chromium.org>
Commit-Queue: Xiaohan Wang <xhwang@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1401593}
Since std::hash has been implemented for StrongAlias, we can remove the
redundant Hasher struct. Mostly this is trivial, although in once case
(AxPlatformNodeId) the type system wasn't able to deduce the correct
hasher automatically, so we provide an explicit specialization.
Bug: 380246463
Change-Id: I299623b8cc8193415cb8771dd455a3cddfa27e1a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6132291
Commit-Queue: Devon Loehr <dloehr@google.com>
Reviewed-by: Peter Kasting <pkasting@chromium.org>
Reviewed-by: Abigail Klein <abigailbklein@google.com>
Owners-Override: Peter Kasting <pkasting@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1401545}
This reverts commit c33526f6ae.
Record metrics and trace events for navigation start adjustments.
These metrics will indicate how large the adjustments are in practice,
and how consistently they are made.
The previous attempt did not account for negative time adjustments,
which unfortunately can occur in practice. This CL allows us to gather
metrics for negative adjustments as well (diff from PS1).
Bug: 385170155
Change-Id: Id10060ae8ef6e225c09442aa8c72784ef56c2898
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6120967
Reviewed-by: Tarun Bansal <tbansal@chromium.org>
Commit-Queue: Charlie Reis <creis@chromium.org>
Reviewed-by: Sharon Yang <yangsharon@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1401543}
DIPS.SuspectedTrackerFlow* and some DIPS.TrustIndicator* are singular events, but were not marked with `singular="True"` when they were added. Simply marking them as singular now is unsafe, so this CL creates V2s of these metrics.
The <summary>s for many of the DIPS.SuspectedTrackerFlow* and DIPS.TrustIndicator* events were also formatted and/or ordered confusingly; this CL hopefully makes them easier to read.
Change-Id: I463c45e3a6b7f033982e66e5d1a3bd745af71177
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6115181
Commit-Queue: Svend Larsen <svend@chromium.org>
Reviewed-by: Sun Yueru <yrsun@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1401468}
The request time on the response head corresponds with the original
request time (for the validated and cached entries), not the new
request time, so this metric wasn't being recorded as expected. Do not
record for the "updated" case because we do not appear to have the
relevant fields for it.
OBSOLETE_HISTOGRAM[Ads.InterestGroup.Auction.HttpCachedTrustedBiddingSignalsAge]=replaced by HttpCachedTrustedBiddingSignalsAge2
Bug: 383579272
Change-Id: I223c3c666f12662b13dc32fcc228f238f42778ae
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6116043
Reviewed-by: Maks Orlovich <morlovich@chromium.org>
Reviewed-by: Orr Bernstein <orrb@google.com>
Commit-Queue: Abigail Katcoff <abigailkatcoff@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1401463}
When creating a payment assertion, load the stored browser bound key id
for the relevant credential and relying party. Before this change secure
payment confirmation would create a new browser bound key. After this
change secure payment confirmation uses the browser bound key that was
previously created (e.g. the browser bound key from credential creation).
This change is behind the flag,
chrome://flags/#enable-secure-payment-confirmation-browser-bound-key
Bug: 377278827, b:378708356
Change-Id: Ia902e9256e4c86de3b2878cfb1c8047df772f7cf
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6101779
Reviewed-by: Avi Drissman <avi@chromium.org>
Reviewed-by: Rouslan Solomakhin <rouslan@chromium.org>
Commit-Queue: Slobodan Pejic <slobodan@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1401411}
The feature was launched in M114, cleaning up the code.
Note: the cleanup was attempted in the past in crrev.com/c/4977161,
but was reverted due to MSAN failures. Some tests were reworked or
removed in the past year, and now there are no failures when I run
the same linux_chromium_chromeos_msan_rel_ng bot, so the cleanup
can be landed again.
Bug: 356624220
Change-Id: Ie8c22105eea8a8f6d5e87cee7daba14f3f324fc5
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6120408
Reviewed-by: Thomas Guilbert <tguilbert@chromium.org>
Commit-Queue: Maria Kazinova <kazinova@google.com>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Reviewed-by: Jordan Bayles <jophba@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1401376}