Auctions are often stuck waiting for processes to be created.
Using the in-memory cache for interest group owners, we can anticipate
which worklet processes to start in parallel to interest group loading.
Bug: 365528726
Change-Id: Id6970baa964c4857ca544b7fb7a6fec6a1b3cf83
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5939361
Reviewed-by: Orr Bernstein <orrb@google.com>
Reviewed-by: mmenke <mmenke@chromium.org>
Commit-Queue: Abigail Katcoff <abigailkatcoff@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1370829}
This feature also partially overlaps with the WebXRLayers feature, but
we don't want to enable all of that when enabling the WebGPU bindings.
To address that a "WebXRLayersCommon" feature was added that is implied
by either the WebXRGPUBinding feature or the WebXRLayers feature and
which only enables the interfaces that are needed by both features.
Bug: 359418629
Change-Id: Ifff19456a6a8f968dc7064953844ba31052f0be8
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5940998
Commit-Queue: Brandon Jones <bajones@chromium.org>
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Reviewed-by: Ian Vollick <vollick@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1370731}
This is a precursor CL to allow SimpleMenuModel to include actions.h, in order to be able to create menu items from action items.
Currently, simple_menu_model cannot include actions, as doing so creates a dependency cycle from ui/base -> ui/actions -> ui/base.
Many of the changes here are simply renaming include paths from ui/base/models -> ui/menus/models. The only significant changes here that need to be reviewed are changes in BUILD.gn and DEPS files.
Change-Id: I345efc6c42bbf2d7fdd539c0b312a8f5db338382
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5892572
Reviewed-by: Nico Weber <thakis@chromium.org>
Reviewed-by: Achuith Bhandarkar <achuith@chromium.org>
Commit-Queue: Joseph Park <josephjoopark@chromium.org>
Reviewed-by: Emilia Paz <emiliapaz@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1370692}
unpartitioned data access attestation check.
Implement the browser client layer check of the new attestation API.
Apply this check for shared storage get.
Browser tests for testing shared storage get with respect to the new
attestation check is added in:
chrome/browser/storage/shared_storage_browsertest.cc.
Update other existing tests to work with this check.
Please note other than the attestation, the local unpartitioned data
access is also gated on 3pc setting. See crrev.com/c/5860019.
Bug: 361375807
Change-Id: I338bb9fa756b9e2b793f3bf4a491281cd41409f6
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5854085
Reviewed-by: Avi Drissman <avi@chromium.org>
Commit-Queue: Xiaochen Zhou <xiaochenzh@chromium.org>
Reviewed-by: Shivani Sharma <shivanisha@chromium.org>
Reviewed-by: Eric Seckler <eseckler@chromium.org>
Reviewed-by: Cammie Smith Barnes <cammie@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1370560}
This CL does the following:
* Implements RenderWidgetHostViewInput interface as
RenderInputRouterSupportAndroid mirroring RenderWidgetHostViewAndroid
class in browser for handling input on Viz with InputVizard. This CL
just adds the skeleton of RenderInputRouterSupportAndroid class's
implementation with bunch of TODO's which are being tracked with bugs
and will be added later in the upcoming CL's. Implementation of
RenderWidgetHostViewChildFrame will be added in an upcoming CL.
Doc Link:
https://docs.google.com/document/d/1tRPUd11fuPcXxb2ep_kGYPahgv0OOlV7DvsGkbom7VA/
Bug: b:367695776
Change-Id: I5e662f1456c9d4ff8cc361d86716ce4f69c3dfa4
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5905858
Commit-Queue: Aman Verma <amanvr@google.com>
Reviewed-by: Hidehiko Abe <hidehiko@chromium.org>
Reviewed-by: Jonathan Ross <jonross@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1370553}
Previous implementation uses a fixed 1080p@30fps configuration and query if GPU factory supports that. As a result, the level of HEVC reported in
SDP offer/answer is always 3.1.
Switch to iterate over the profiles/resolutions reported from GPU factory and use that to create supported format lists for HEVC.
Bug: 41480904, 368478704
Change-Id: I8bf895a734789299cda7faad70e6d840025ffedb
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5880164
Reviewed-by: Eugene Zemtsov <eugene@chromium.org>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Antonio Rivera <antoniori@google.com>
Commit-Queue: Jianlin Qiu <jianlin.qiu@intel.com>
Cr-Commit-Position: refs/heads/main@{#1370549}
All released version of B&A support both the new and old fields. The
new field allows the B&A server to provide the same precision to
worklets as is available in on-device auctions.
Bug: 374088337
Change-Id: Ia1a5d40501da41300c7d9fd5e4e3bd7bfc8303ab
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5940498
Reviewed-by: Maks Orlovich <morlovich@chromium.org>
Commit-Queue: Russ Hamilton <behamilton@google.com>
Cr-Commit-Position: refs/heads/main@{#1370523}
Some Intel GPUs don't support QP less than 10 on h264.
Unfortunately currently we don't have a way for web API to communicate supported
QP range.
Bug: 333426465
Change-Id: Id897015dde14b820ba9954ddb8ef98c5c0e7d420
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5941642
Reviewed-by: Brian Sheedy <bsheedy@chromium.org>
Commit-Queue: Eugene Zemtsov <eugene@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1370458}
DedicatedStyleAuctionProcessManagerTest was inheriting from
AuctionProcessManagerTest instead of AuctionProcessManagerTestBase.
As a result of this, DedicatedStyleAuctionProcessManagerTests had access
to methods that operated on the AuctionProcessManager created in
AuctionProcessManagerTest, instead of
DedicatedStyleAuctionProcessManagerTest's own AuctionProcessManager.
Inheriting from the base class prevents this issue, since it doesn't
create its own process manager.
Bug: none
Change-Id: Ia742e01e279aa2bfb0c876a2db21468a85c3bc18
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5940145
Commit-Queue: mmenke <mmenke@chromium.org>
Reviewed-by: Abigail Katcoff <abigailkatcoff@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1370296}
Adds a new UMA metric ("Preloading.Prefetch.PrefetchStatus") to record
the final PrefetchStatus value** of a PrefetchContainer.
** For prefetches with a "failure" status, we record the first failure
status set; which may not be the final one.
Bug: 365376512
Change-Id: I93e9df7f4427ea60c04fcf72efd9a7180f85f307
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5925314
Reviewed-by: Taiyo Mizuhashi <taiyo@chromium.org>
Reviewed-by: Max Curran <curranmax@chromium.org>
Reviewed-by: Hiroki Nakagawa <nhiroki@chromium.org>
Commit-Queue: Adithya Srinivasan <adithyas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1370141}
What: Check privacy sandbox settings for interestGroups().
How:
1. Add `browser_context` to the `IsInterestGroupAPIAllowed()` parameters
to get the `PrivacySandboxSettings` for general permission check.
This is because `render_frame_host` can be null (e.g., due to the
initiator frame being destroyed and the worklet is in keep-alive
phase). In this case, certain operations like console error will
be skipped, but the core permission check will still be
performed.
2. Introduce and use a new InterestGroupApiOperation::kRead type.
Bug: 367992703
Change-Id: I9e1b44efc3f67a408433e6284be82197bb594a73
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5936920
Reviewed-by: Andrey Kosyakov <caseq@chromium.org>
Reviewed-by: Russ Hamilton <behamilton@google.com>
Reviewed-by: Fiona Macintosh <fmacintosh@google.com>
Reviewed-by: Ben Kelly <wanderview@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Commit-Queue: Yao Xiao <yaoxia@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1370140}
This reverts commit a56e352a2b.
Reason for revert: There are several bugs, some fixed on ToT
(crbug.com/348520453, crbug.com/367166494), some
still need investigation (crbug.com/372722559). We need to unlaunch
the feature and restart the experiment after all bugs are fixed.
Original change's description:
> [HitTestOpaqueness] Enable by default
>
> Also change status of FastNonCompositedScrollHitTest to stable to make
> it merely depend on the status of RasterInducingScroll, to simplify
> dependencies.
>
> Bug: 40062957, 40256365, 329115115
> Change-Id: Ia675bf7a2e833f26f3c113bda12735317d218a07
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5824528
> Reviewed-by: Philip Rogers <pdr@chromium.org>
> Commit-Queue: Xianzhu Wang <wangxianzhu@chromium.org>
> Reviewed-by: Jonathan Ross <jonross@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#1348709}
Bug: 40062957, 40256365, 329115115
Change-Id: Ibeeeed2eda9365c850c174ca0854bba9ba77855a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5941138
Commit-Queue: Xianzhu Wang <wangxianzhu@chromium.org>
Reviewed-by: Philip Rogers <pdr@chromium.org>
Reviewed-by: Dave Tapuska <dtapuska@chromium.org>
Reviewed-by: Jonathan Ross <jonross@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1370123}
The BlobStorageBrowserTest.BlobCombinations test performs some blob
operations through a test JS file and expects the memory usage and disk
space usage of BlobMemoryController to be non-zero. In some test runs,
however, all the new memory and disk allocations get revoked by the time
the posted task to measure the current memory and disk usage runs, and
hence the test fails.
Memory and disk allocations start getting revoked right after the blobs
have been transferred to their destination, so it's incorrect to expect
point-in-time usage of memory and disk space in the controller to be
non-zero always. There is sufficient unit-test coverage for the usages
already, so this CL removes these expectations from the browser test.
Memory and disk allocations start getting revoked soon a
Bug: 363225483
Change-Id: I9a747285df5333a0c3e2db5a90075b54e7fa18a1
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5929408
Reviewed-by: Evan Stade <estade@chromium.org>
Auto-Submit: Abhishek Shanthkumar <abhishek.shanthkumar@microsoft.com>
Commit-Queue: Abhishek Shanthkumar <abhishek.shanthkumar@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#1370102}
This removes the need for a non-trivial destructor. Exceptions can
still be caught if needed with v8::TryCatch.
In order to keep dictionary-conversion exception messages the same,
add DictionaryFromV8Context (very similar to
ExceptionState::ContextScope, which was removed in
https://chromium-review.googlesource.com/c/chromium/src/+/5867470).
Binary-Size: reversing some of the binary size win in the above CL
Fuchsia-Binary-Size: reversing some of the binary size win in the above CL
Bug: 328104148
Change-Id: I017294ff9bbec31798e2ed7a40ebaea07d7bc940
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5882467
Reviewed-by: Andrey Kosyakov <caseq@chromium.org>
Owners-Override: Nate Chapin <japhet@chromium.org>
Commit-Queue: Nate Chapin <japhet@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1370066}
The API already exists, and outer response parsing is the same for
bidding and scoring signals, so this only adds code to create the CBOR
for scoring signals requests.
Bug: 333445540
Change-Id: I7fcf9363bcb1aa7932f7f9900281484506c32ddc
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5938446
Reviewed-by: Russ Hamilton <behamilton@google.com>
Commit-Queue: mmenke <mmenke@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1370027}
In Android browser tests, a new renderer can try to establish a new mojo
pipeline after the DiscardableSharedMemoryManager is reset, making
DiscardableSharedMemoryManager::Get() a nullptr.
The remedy is to partially "revert" https://crrev.com/c/1670289
Tested: with the Fieldtrial testing config added, `autoninja -C out/android android_browsertests && out/android/bin/run_android_browsertests -f SearchPreloadUnifiedBrowserTest.PrerenderHintReceivedAfterSucceed --fast-local-dev --gtest_repeat=100 --break-on-failure` passed.
Cq-Include-Trybots: luci.chromium.try:android-12-x64-rel,android-12l-x64-dbg,android-13-x64-rel,android-14-x64-rel,android-15-x64-rel,android-pie-x86-rel,android-oreo-x86-rel
Fixed: 373698143
Change-Id: I0d0574759841915ac16d05417c3994447355e39b
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5932591
Reviewed-by: Khushal Sagar <khushalsagar@chromium.org>
Commit-Queue: William Liu <liuwilliam@chromium.org>
Reviewed-by: danakj <danakj@chromium.org>
Reviewed-by: Dave Tapuska <dtapuska@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1369985}
This CL adds a feature parameter
`kPrerender2FallbackPrefetchReusablePolicy` to control the behavior of
multiple use of prefetch, mainly for prerender integration.
In particular, with option `kUseIfIsLikelyAheadOfPrerender`, this CL
makes prefetch ahead of prerender reusable partially to prevent the
second fetch when a prefetch is started with `IsLikelyAheadOfPrerender`
and a prerender initial navigation used the prefetch result and failed,
e.g. due to use of forbidden mojo interface.
Note that this CL doesn't make a prefetch reusable if it is started by a
SpeculationRules of "prefetch" and then marked as
`IsLikelyAheadOfPrerender` by a SpeculationRules of "prerender".
Fixed: 372444497
Change-Id: I5a8e69b8243c2f4b185054cca79afe721fc6f8d2
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5923166
Reviewed-by: Hiroki Nakagawa <nhiroki@chromium.org>
Commit-Queue: Ken Okada <kenoss@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1369918}
This is a reland of commit 33493d2d85
This restores a branch in RenderViewHostImpl::CreateRenderView() that
was mistakenly removed in the original CL.
Original change's description:
> [prerender] Fix crash when discarding a speculative main RenderFrameHost
>
> Previously, starting a prerender navigation would create a speculative
> RenderFrameHost for the root frame tree node in the browser process.
> However, the corresponding RenderFrame in the renderer process would
> be created as the active/current main RenderFrame. This is a result of
> the interaction between `CreateProxiesForSiteInstanceGroup()`, which
> skips creating a proxy if it thinks the early commit optimization will
> be used, and `PerformEarlyRenderFrameHostSwapIfNeeded()`, which skips
> performing early commits in prerendering frame trees.
>
> Intentional or not, this is problematic because:
>
> - The browser process assumes speculative RenderFrameHosts can be
> cleaned up by deleting the corresponding RenderFrame in the renderer
> process.
> - The renderer process assumes the active/current main RenderFrame is
> never explicitly deleted, and that it will only be implicitly deleted
> as a side effect of explicitly deleting its blink::WebView.
> - Blink assumes a blink::WebView always has an active main frame (i.e.
> non-null). Rather than crashing non-deterministically, the renderer
> process CHECK-fails if the browser tries to explicitly delete a
> non-provisional main RenderFrame.
>
> Taken together, this means discarding a speculative main RenderFrameHost
> during a prerender navigation will crash the renderer process. Needless
> to say, this is not desirable. Previous fixes have centered around
> identifying the cases that would discard a speculative RenderFrameHost
> and disabling prerendering for those cases.
>
> However, this doesn't fix the underlying issue and ends up being a game
> of whack-a-mole. This CL implements a proper fix: the corresponding
> main RenderFrame in the renderer process is now created as a provisional
> frame during a prerender navigation. This is implemented using a
> placeholder RemoteFrame; RenderDocument already uses this concept for
> local -> local frame swaps.
>
> This CL also refactors several ancillary components to make the updated
> logic easier to follow:
>
> - Rather than using a non-null `previous_frame_token` as the implicit
> signal for creating a provisional main local frame, Mojo now uses the
> CreateProvisionalLocalMainFrameParams variant subtype to convey this
> intent. This is a required cleanup, since prerender navigations should
> not set a `previous_frame_token`, but still want the placeholder
> RemoteFrame + provisional LocalFrame behavior.
> - With the updated union, the different main frame cases are also broken
> out more distinctly in `AgentSchedulingGroup::CreateView()`.
> - Rename `EnsureWidgetInitialized()` to `InitializeWidgetAtSwap()`,
> since that is the only situation it is called.
> - Remove `previous_frame_token_for_compositor_reuse` from the frame
> widget creation params, and replace it with the `reuse_compositor`
> bool. The frame token is redundant, since the frame widget creation
> params are always paired with frame creation params.
> - Refactor `WillDetach()` and `InitializeWidgetAtSwap()` to account for
> the removal of `previous_frame_token_for_compositor_reuse`. It turns
> out the renderer process already has all the information needed to
> determine the previous frame; passing it directly significantly
> simplifies this coordination.
>
> Finally, this also removes the crash instrumentation that was previously
> added to help track down situations where prerender navigations would
> discard speculative main RenderFrameHosts. Since this no longer crashes,
> the instrumentation is no longer needed.
>
> Bug: 40076091
> Change-Id: I1c19853c75580492653e608afb1db3442a264b3a
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5922799
> Reviewed-by: Dave Tapuska <dtapuska@chromium.org>
> Commit-Queue: Daniel Cheng <dcheng@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#1369647}
Bug: 40076091
Change-Id: I10ecdf8233f6dfd42e0478c819447831d50256c3
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5937586
Reviewed-by: Dave Tapuska <dtapuska@chromium.org>
Commit-Queue: Daniel Cheng <dcheng@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1369798}
Previously, touch event feature detection was only enabled on Android by
default. This led to certain touch events (such as ontouchstart and
ontouchend) not being found in window and document. Since iOS also
employs the blink engine with USE_BLINK = true, touch feature detection
should be enabled for iOS as well.
Bug: 40254930
Change-Id: I120ad70251287a9edd89ae0e0834083c406e0dc7
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5933085
Reviewed-by: Dave Tapuska <dtapuska@chromium.org>
Reviewed-by: Leon Han <shulianghan@microsoft.com>
Commit-Queue: Lichen Liu <lichenliu@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#1369765}