Currently last input event, which is time-sensitive, is considered for
AttributionSuitableContext comparison.
The last input event is needed for navigation-tied OS source
registrations. Due to time-sensitivity, the last input event may vary
for registrations associated with the same navigation, therefore
possibly leading to inequivalent contexts for those registrations.
This cl ignores last_input_event for AttributionSuitableContext
comparison, and the last input event for the first registration of the
navigation will be used for all subsequent registrations for the
corresponding navigation.
Bug: 386277791
Change-Id: I46b1de8d31790edae0d0e97c231c90f35d456068
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6169262
Commit-Queue: Nan Lin <linnan@chromium.org>
Reviewed-by: Andrew Paseltiner <apaseltiner@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1405640}
- WebFrameWidgetImpl::OnStartStylusWriting
Add a missing coordinate-space transformation from DIP widget space
to Blink Space. This fixes a hit testing issue when using different
device display scaling.
- TSFTextStore::GetACPFromPoint
RenderWidgetHostViewAura::GetProximateCharacterIndexFromPoint
Instead of converting each proximate bounding box from a (cached)
DIP widget space rect to a physical screen rect, converting the
single API point from physical screen space to DIP widget space.
Renaming a bunch of stylus handwriting specific function arguments to
reflect which coordinate space they expect for point and rect inputs.
Bug: 355578906
Change-Id: I719bbcfa1057187391abbbb24429d0b118204c01
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6128720
Reviewed-by: Dana Fried <dfried@chromium.org>
Commit-Queue: Adam Ettenberger <Adam.Ettenberger@microsoft.com>
Reviewed-by: Mustafa Emre Acer <meacer@chromium.org>
Reviewed-by: Dave Tapuska <dtapuska@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1405629}
The are few callsites that can pass gpu_compositing = false, they are
renambed to ToClosestSkColorTypeDeprecated, so we can work on
eliminating them.
Hardcoding to N32 was needed only for SharedBitmaps.
Bug: 383575394
Change-Id: Idf22d09ece603b54ae2c8a485f21f1390267a354
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6089238
Reviewed-by: Colin Blundell <blundell@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Commit-Queue: Vasiliy Telezhnikov <vasilyt@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1405518}
On some platforms, the cost of retrieving the VEA supported profile
is too high. For example, on Windows, the Media Foundation VEA's
call to `GetSupportedProfiles()` will approximately take 850
milliseconds and cause the GPU process's memory usage to increase
by 50MB. Due to this excessive overhead, we have no choice but to
switch to an on-demand and synchronous approach to get the VEA
configs.
As a result, when `MediaRecorder.isTypeSupported()` that
checks for a non-builtin codec is called or when a MediaRecorder
instance is created for the first time, there will be a synchronous
stutter of approximately 1 second in extreme cases (e.g. Windows).
Since we don't retrieve the profile immediately after starting the
render process, this CL can at least solve the current problem of
additional GPU process memory usage and cpu cost.
Meanwhile, this CL also changes how `media::IsEncoderSupportedVideoType()`
calls RenderClient delegate. The actual profile acquisition operation
of `RenderClient->IsEncoderSupportedVideoType()` is adjusted to be
executed based on the specific video type. In this way, it can be
ensured that when a codec is a built-in codec (e.g. vp8/vp9, h.264 &
av1 on non-android platform), the result can be directly returned
without having to make a blocking call to the function of
`RenderClient->IsEncoderSupportedVideoType()`.
Bug: 377100050
Bug: 40276507
Change-Id: Ib76e3b2a4c162a39b6d8db026b8f8dc8a55688f0
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6151780
Reviewed-by: Dale Curtis <dalecurtis@chromium.org>
Commit-Queue: Sida Zhu <zhusida@bytedance.com>
Cr-Commit-Position: refs/heads/main@{#1405133}
Due to stale states and early returns, `handleDragStopped()` was not
called after certain cross-process navigations. This meant text
magnifier did not always dismiss when renderer process changed.
See bug for more details.
To fix this, we call `handleDragStopped()` when
`SPC::UpdateRenderProcessConnection()` is called to dismiss the text
magnifier. This ensures dismissal after renderer process changes.
Fixed: 384033062
Change-Id: I158529d40dba86f21b275c7031531797498635dc
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6093444
Reviewed-by: Jinsuk Kim <jinsukkim@chromium.org>
Commit-Queue: Alesandro Ortiz <alesandro@alesandroortiz.com>
Reviewed-by: Bo Liu <boliu@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1405064}
Follow-on CL to crrev.com/c/6121689 moving DIPS code from chrome/ to content/.
Some tests were newly flaky, so I fixed the ones that I could fix quickly, and disabled the ones that I couldn't find an immediate fix for. Note that this is still a net reduction in untested production code from before this CL, as the code is live but the tests aren't being run.
Bug: 40883201
Change-Id: I96531e249bc2d521d638f87ad0d2b0dbe45262d2
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6138066
Auto-Submit: Svend Larsen <svend@chromium.org>
Reviewed-by: Ryan Tarpine <rtarpine@chromium.org>
Commit-Queue: Svend Larsen <svend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1404993}
InterestGroupAuction already has logic to find the chosen ad, and keeps
a raw pointer to it, so can pass that in to the reporter. The main
motivation here is to avoid the algorithms diverging in case we ever
add extra logic here (e.g., maybe another field that matches, or maybe
smarter disambiguation when two ads have the same URL but different
sizes, or somesuch).
Also remove an unnecessary std::move() in WinningBidInfo's constructor,
since it takes its only argument as a const ref.
Bug: None
Change-Id: I87f8a0b97f1ef5453471b3e5588652ddd47e3e06
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6159050
Commit-Queue: mmenke <mmenke@chromium.org>
Reviewed-by: Maks Orlovich <morlovich@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1404816}
Adds a test (though this will eventually be removed when this feature is
cleaned up) that shows that a runtime-disabled field (in this case
`selectableBuyerAndSellerReportingIds`) is ignored when joining an
interest group, but the rest of the interest group is joined
successfully.
Change-Id: Iba469868a3814811289b754ef41b8085ecc893d8
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6163884
Reviewed-by: Maks Orlovich <morlovich@chromium.org>
Commit-Queue: Orr Bernstein <orrb@google.com>
Cr-Commit-Position: refs/heads/main@{#1404796}
We want to know if past bids are predictive of an interest group's
being filtered. If they are, we can use past bids in heuristics to
determine the number of threads and contexts to create for an owner.
Bug: 388877000
Change-Id: Ie94e2edd3d0776ffc8df8e1e17a3e42f14c39b72
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6164048
Commit-Queue: Abigail Katcoff <abigailkatcoff@chromium.org>
Reviewed-by: Orr Bernstein <orrb@google.com>
Cr-Commit-Position: refs/heads/main@{#1404770}
Updates the GPU pixel tests which force a context loss to restart the
browser afterwards as a tentative fix for flakes in subsequent tests.
This requires two related changes:
1. A new post-test hook is defined that GpuIntegrationTest calls
since restarting the browser in the test method breaks the
expected crash checks that GpuIntegrationTest performs.
2. Adding support for specifying platform-specific expected crashes.
This allows us to work around Fuchsia-specific weirdness related
to how expected crashes are checked that has been uncovered due
to changing when the browser is restarted as part of #1.
Bug: 382422293
Change-Id: I3a4a7cb75247776f7836bfcadb7a639893a03cf9
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6160817
Auto-Submit: Brian Sheedy <bsheedy@chromium.org>
Commit-Queue: Yuly Novikov <ynovikov@chromium.org>
Reviewed-by: Yuly Novikov <ynovikov@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1404724}
The CL adds mojo binding for the language detection in workers. This
will fix the test failures in the corresponding WPT tests.
The CL also updates the WPT test to run in all types of workers.
Bug: 368206184, 388961572
Change-Id: I45f0632bd7df1ed403f88b398494019ea7a35679
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6148112
Reviewed-by: Hidehiko Abe <hidehiko@chromium.org>
Reviewed-by: Tsuyoshi Horo <horo@chromium.org>
Commit-Queue: Jiacheng Guo <gjc@google.com>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1404644}
We had been using a dummy value of 1 for creating MotionEvent objects in
Viz. In this change we are passing the device scale factor as part of
touch transfer state. This does add an assumption that the device scale
factor remains constant during a touch sequence. Making this assumpiton
seems safe since user would have not normally be able to change it mid
touch sequence, even if they do it results in activity restart and a
touch cancel which terminates touch sequence as stated below.
Doing a simple test where I change device scale factor mid sequence
using this command: `$ adb shell wm density <value>`.
- This results in activity restart and a touch cancel is generated which
terminates the sequence.
- However one touch move did get the updated device scale factor before
touch cancel was received.
Bug: 370506271
Change-Id: Ie98ce7096c8edf9fb059374ef5c867dc3fcfb082
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6151755
Commit-Queue: Kartar Singh <kartarsingh@google.com>
Reviewed-by: Arthur Sonzogni <arthursonzogni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1404588}
Browser was already brokering a connection between Viz and Browser for
RenderInputRouterClient interface. In this change we are setting up
following connections between Viz and Renderer using
RenderInputRouterClient interface:
- WidgetInputHandler: To send input events to Renderer.
- InputTargetClient: For asynchronous hit testing.
Following connections are not established between Viz and Renderer:
- FrameWidgetInputHandler: IME, text selection will not be handled by
Viz.
- WidgetInputHandlerHost: Browser will continue to act as only host.
Bug: 370506271, 382291983
Change-Id: Ia168aa86ca560f259cc0b2b0fd90295df7e96d90
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6073148
Reviewed-by: Dave Tapuska <dtapuska@chromium.org>
Commit-Queue: Kartar Singh <kartarsingh@google.com>
Reviewed-by: Antonio Sartori <antoniosartori@chromium.org>
Reviewed-by: Stephen Nusko <nuskos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1404587}
The initial implementation failed to check for reserved name (i.e.,in
https://w3c.github.io/web-locks/#resource-name: "Resource names
starting with U+002D HYPHEN-MINUS (-) are reserved; requesting these
will cause an exception."). Thus, we check the name at mojom
requester site, as well as during serialization.
Fuchsia-Binary-Size: Size increase is unavoidable.
Bug: 373899210,385341236
Change-Id: I208d03d74a9ce89ef74eb39784d9e6bef0d5ecff
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6109617
Reviewed-by: Maks Orlovich <morlovich@chromium.org>
Reviewed-by: Giovanni Ortuno Urquidi <ortuno@chromium.org>
Commit-Queue: Yao Xiao <yaoxia@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1404554}
This CL removes a warning in SpeechRecognizerImpl that is no longer
accurate. If the Web Speech API is used with a MediaStreamTrack,
there will be no input audio parameters. Audio parameters from the
MediaStreamTrack may be set after speech recognition starts.
Change-Id: I620d8252f5b0ec31edea67c57d8e686ca80b3fbd
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6164609
Commit-Queue: Evan Liu <evliu@google.com>
Reviewed-by: Yiren Wang <yrw@chromium.org>
Auto-Submit: Evan Liu <evliu@google.com>
Commit-Queue: Yiren Wang <yrw@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1404504}
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}
This mainly consists of implementing onpreferredsizechanged as the
extensions page doesn't show the options dialog until it receives that
event.
The tests for extensionoptions are parameterized to run with both
the existing inner WebContents implementation and MPArch.
Since the extension settings are loaded in a tab, events from the guest
will be observed by TabHelpers, whereas with the existing
implementation, only observers which explicitly observed guest
WebContents would get the events. StorageAccessAPITabHelper needs to
account for this.
Bug: 40202416
Change-Id: Ic3a4e23ddce53dc3f069cf2e8d18d389a4464fc1
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6160064
Reviewed-by: Emilia Paz <emiliapaz@chromium.org>
Reviewed-by: Dave Tapuska <dtapuska@chromium.org>
Reviewed-by: Shuran Huang <shuuran@chromium.org>
Commit-Queue: Kevin McNee <mcnee@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1404437}
Guarded by net::feature flag DisallowNonAsciiCookies,
when a cookie's name or value contains a non-ascii value,
this cookie will be excluded. This feature is disabled by
default.
Bug: 40061459
Change-Id: Ib853b730568065a5a73d699a1cac51c548c72a40
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6123584
Reviewed-by: Maks Orlovich <morlovich@chromium.org>
Reviewed-by: Steven Bingler <bingler@chromium.org>
Commit-Queue: Amarjot Gill <amarjotgill@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1404400}
This is a reland of commit fb5f6b4447
Changes from original CL:
* Made the new code a no-op when running in Webview since
chrome://gpu does not exist in that browser
Original change's description:
> Capture about:gpu as an artifact
>
> Updates the GPU Telemetry-based tests to capture a plaintext version of
> about:gpu / chrome://gpu as a test artifact. The information is only
> retrieved when the browser is restarted with different args, so no
> additional work is done for almost every browser start.
>
> There was no significant difference in runtime with this applied when
> running a subset of the WebGPU CTS suite with ResultDB enabled.
>
> Bug: 376498163
> Change-Id: I574a48463f4824587fc8e5d077ebaba55b467094
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5984535
> Reviewed-by: Yuly Novikov <ynovikov@chromium.org>
> Commit-Queue: Yuly Novikov <ynovikov@chromium.org>
> Auto-Submit: Brian Sheedy <bsheedy@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#1403696}
Bug: 376498163
Change-Id: I957031a27cfee64df85525da0a38a335173828ef
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6164140
Commit-Queue: Brian Sheedy <bsheedy@chromium.org>
Reviewed-by: Yuly Novikov <ynovikov@chromium.org>
Commit-Queue: Yuly Novikov <ynovikov@chromium.org>
Auto-Submit: Brian Sheedy <bsheedy@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1404389}
Move ShouldDeleteInteractionRecords() from DipsDelegate to
ContentBrowserClient, renaming it ShouldDipsDeleteInteractionRecords().
Now that there are no methods left on DipsDelegate, delete it (and
ChromeDipsDelegate).
Bug: 387281262
Change-Id: I020b806a1526a46095425a0a637ec273ca50b4f2
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6142815
Commit-Queue: Ryan Tarpine <rtarpine@chromium.org>
Reviewed-by: Joshua Hood <jdh@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1404371}
Making sure that we don't accidental new code paths assuming
that if the first frame had certain pixel format or storage type, then
then all consequent frame will have the same pixel format and storage type.
Bug: 40162806
Change-Id: I1696839dff8e954be66e5a75a907d608903af41f
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6161556
Reviewed-by: Brian Sheedy <bsheedy@chromium.org>
Commit-Queue: Eugene Zemtsov <eugene@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1404344}
This CL moves the logic to make PRF salts into the PRFInput class.
This will allow the code to hash PRF values into salts to be
reusable across platforms.
Bug: 355045497
Change-Id: I1ec4668b77ad6622744a221cc891dc1522371b50
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6163871
Reviewed-by: Martin Kreichgauer <martinkr@google.com>
Commit-Queue: Alexis Hétu <sugoi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1404336}
A fuzzer exposed a very real issue here where the following sequence is
possible:
- [1]VideoCaptureHost::Start
- creates entry in `controllers_`
- async ConnectClient call with good params
- VideoCaptureHost::DeleteVideoCaptureController
- deletes entry in `controllers_`
- [2]VideoCaptureHost::Start
- creates entry in `controllers_`
- async ConnectClient call with bad parameters
- [1]VideoCaptureHost::OnControllersAdded
- sets entry in `controllers_` to VideoCaptureController object
- causes controller to hold raw pointer to VideoCaptureHost object
- [2]VideoCaptureHost::OnControllersAdded
- deletes entry in `controllers_`
- VideoCaptureHost::~VideoCaptureHost
- `controllers_` is now empty, so VideoCaptureController is not
notified about the destruction of this object
- VideoCaptureController::StopSession
- uses the raw pointer to VideoCaptureHost after free
There are a few possible fixes:
- DeleteVideoCaptureController could be changed so that if the
controller attempting to be deleted is not yet initialized,
then it does not erase it. Since that initialization will
finish at some point, it does not leak in some uninitialized
state forever. This is what I opted for, but it does mean that
Start->Delete->Start pattern will essentially drop the second
start, which might not be ideal.
- disallow VideoCaptureHost::Start while another is in progress. This
would be slightly more difficult, as some extra map would have to
track that progress, and the end result of Start->Delete->Start is to
just have nothing started at all, which might be more correct
however.
- Attach a unique token to each Start sequence, which would then
stop the initialization process if it's been deleted preemptively.
This is again a bit more code, and I'm not sure what the right answer
is for the final state after Start->Delete->Start.
Bug: 385466113
Change-Id: I984beed247dba2298bb45517a34ba284de8902c8
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6161534
Commit-Queue: Ted (Chromium) Meyer <tmathmeyer@chromium.org>
Reviewed-by: Mark Foltz <mfoltz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1404315}
