TransformPointToLocalCoordSpace.
TransformPointToLocalCoordSpace takes a viz::SurfaceId but only uses the
FrameSinkId part of it to transform a point to another coordinate space.
This CL removes the redundant viz::SurfaceId and passes the
viz::FrameSinkId directly to the method.
Bug: b/358566970
Change-Id: I694262195daa93a7abe2cbd418777510ca0ac90c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5853962
Reviewed-by: Stephen Nusko <nuskos@chromium.org>
Commit-Queue: Aman Verma <amanvr@google.com>
Cr-Commit-Position: refs/heads/main@{#1356433}
Instead code must use showSaveFilePicker() to get a handle on a new file
and copy the file to the new location, and optionally delete the old
file.
Bug: 40101963
Change-Id: Ic584b14ca024dff08d17efce9e851e8df5c3fd0d
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5839974
Reviewed-by: Austin Sullivan <asully@chromium.org>
Commit-Queue: Joel Hockey <joelhockey@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1356317}
* Add java-side functions for getting file info and listing files
in a dir.
* Update file_util_posix to use new GetFileInfo which handles dirs.
* Update FileEnumerators for handling content-URIs.
* Update FSADirectoryHandle to handle content-URIs and join child
documentIds with parent dir treeUris.
Bug: 40101963
Low-Coverage-Reason: COVERAGE_UNDERREPORTED tests from c++ exercise Java
Change-Id: I7e9b50400c8690862050e2e4bba6af80e4054a22
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5785427
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Commit-Queue: Joel Hockey <joelhockey@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1356301}
This CL contains more renaming from AITextSession to AIAssistant.
It also updates some minor things from the other AI related files
including exception refactoring and comment changes.
Bug: 355967885
Change-Id: I8d53f76e0d93f06068e8428ffed0061306416a87
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5850061
Reviewed-by: Jiacheng Guo <gjc@google.com>
Commit-Queue: Mingyu Lei <leimy@chromium.org>
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1356277}
Add trusted bidding signals KVv2 support in
TrustedSignalsRequestManager.
This CL is primarily a wiring change that imports some helper methods
from previous CLs, containing a significant number of error messages,
totaling about 2k. Another reason for its complexity is that this CL
invokes both the request builder and response helper, making it
difficult to split them into two parts for testing purposes (as they
must handle encryption and decryption simultaneously using a saved
context). While it may be possible to pass the trybots by reducing the
length of the error strings and adding them back in a subsequent CL,
this seems unnecessary.
Bug: 337917489
Change-Id: If699cd280b9ef958a63a514ef3882fac026f7648
Binary-Size: See commit description.
Fuchsia-Binary-Size: See commit description.
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5769805
Reviewed-by: mmenke <mmenke@chromium.org>
Commit-Queue: Tianyang Xu <xtlsheep@google.com>
Cr-Commit-Position: refs/heads/main@{#1356264}
In order for VEAs to be able to access shared images, they need to get
a SharedImageManager and (at least on Windows) the same device on which
those textures were created. To do this, plumb through the GpuChannel's
channel token from where the encoder is created in the renderer, through
mojo, to the factory that creates the VEA implementation. The VEA can
then use the channel token to create a CommandBufferHelper, giving it
access to SharedImageManager and a shared graphics device.
See http://crrev.com/c/5758929 for how this change fits in to allow
MFVEA to use shared images for encode.
Bug: 40162806
Change-Id: I6e1ea94e23b061004c79dd59b8b8937f07130eed
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5800417
Reviewed-by: Sunny Sachanandani <sunnyps@chromium.org>
Reviewed-by: Will Harris <wfh@chromium.org>
Reviewed-by: Mark Foltz <mfoltz@chromium.org>
Commit-Queue: Matthew Andrews <mattandr@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#1356260}
Adds infrastructure to plumb hand joint data from tests into runtimes.
Unfortunately, this bumps the `ControllerFrameData` past the heuristic
where it is now "Complex" and needs explicit out-of-line constructor,
destructor, copy, and move operators. This in turn exposed some less-
than-ideal build configurations which are now cleaned up by way of a
new test hook component.
In order to decrease dependency on vr_service, XRHandJointData was moved
to its own mojom file as well. This uncovered an unneeded dependency
from vr_service onto browser_test_interfaces.mojom, which could now be
removed.
It does also appear that the vr_test_hook's usefulness is perhaps
somewhat questionable, as both the actual tests and test hook wrappers
translate from mojom types into test_hook types. We should really
investigate either typemapping or simply using the mojom types directly,
but attempting to do so quickly unveiled a lot of patterns that would
need to be cleaned up that were out of the scope of this CL, which is
aiming to add infrastructure to allow some basic tests that plumb up
hand joint data.
Bug: 359418633
Change-Id: Ib60f6c8ed9c420e481bb4d0d69ea30dc00f3374f
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5847889
Reviewed-by: Matthew Denton <mpdenton@chromium.org>
Commit-Queue: Alexander Cooper <alcooper@chromium.org>
Reviewed-by: Brian Sheedy <bsheedy@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1356216}
We want to know how many navigations potentially could've restored a
BFCached page but couldn't because it's not a history navigation/not
navigating to the entry. This CL adds a histogram to measure that.
Bug: 366394181
Change-Id: I5b855a451f85614967725b889261de4de485fd31
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5857086
Auto-Submit: Rakina Zata Amni <rakina@chromium.org>
Commit-Queue: Rakina Zata Amni <rakina@chromium.org>
Reviewed-by: Charlie Reis <creis@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1356213}
Every top-frame response for a popin must include a Popin-Policy header
that permits the popin's opener's top-frame-origin. This is to ensure
popins cannot be opened in a partitioned context other than the one they
are designed to.
This CL implements the core logic, but makes the default policy *
(allowing all existing tests to work).
The next CL will flip the default to none (requiring existing tests to
be fixed up).
These two parts were split so that review of core logic wouldn't get
lost in the noise of random test changes.
Explainer: https://explainers-by-googlers.github.io/partitioned-popins/
I2P: https://groups.google.com/a/chromium.org/g/blink-dev/c/ApU_zUmpQ2g/
Bug: 340606651
Change-Id: I950d13eb52c64ddc17b6de3fbde2c1c8c0f8ba1c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5861175
Auto-Submit: Ari Chivukula <arichiv@chromium.org>
Commit-Queue: Rakina Zata Amni <rakina@chromium.org>
Reviewed-by: Dana Fried <dfried@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1356211}
Previously it used RenderFrameHostImpl::IsInPrimaryMainFrame()
which won't return true for speculative/pending commit RFH
when this function is called on ReadyToCommitNavigation for
a navigation that commits a new RFH. This CL makes it so that
it checks whether it's the outermost main frame, and the
FrameTree's page is the primary page (instead of prerendering
page etc).
Bug: 364805115
Change-Id: I62a95211b2a5224aabf9aa0bf2eaeec0e9b42efa
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5861629
Commit-Queue: Rakina Zata Amni <rakina@chromium.org>
Reviewed-by: Paul Irish <paulirish@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1356210}
This reverts commit e19949bb75.
Reason for revert: May cause flakiness on asan or builders on low
perf platforms.
Original change's description:
> Use v8::ExceptionPropagationCallback to set exception context information
>
> This new v8 callback provides us an opportunity to modify the
> exception immediately before it is thrown. We can use this callback
> to add context information to the exception message, rather than
> rely on the current system of having a stack-allocated object
> (ExceptionState) apply this information, with the eventual goal
> of either removing this stack-allocated class or rendering its
> constructor/destructor trivial.
>
> Practical results of this change:
> 1. Special handling is need for any case that throws an exception
> asynchronously, or rejects a promise with an exception. In those
> cases, ApplyContextToException() must be called manually.
> 2. A bunch of cases where we previiously couldn't apply exception
> context information now get it for free, so there are a lot of
> test updates to add exception context.
>
> Bug: 328104148
> Change-Id: Icef838874583f48a23036d8604402ceaad11ff25
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5530624
> Reviewed-by: Rick Byers <rbyers@chromium.org>
> Owners-Override: Rick Byers <rbyers@chromium.org>
> Reviewed-by: Andrey Kosyakov <caseq@chromium.org>
> Commit-Queue: Nate Chapin <japhet@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#1355428}
Cq-Include-Trybots: luci.chromium.try:fuchsia-x64-cast-receiver-dbg
Bug: 328104148
Change-Id: I68d71ddc2392aab62a3446204f99e4e67adc5a74
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5867091
Commit-Queue: Zijie He <zijiehe@google.com>
Reviewed-by: Nate Chapin <japhet@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Owners-Override: Nate Chapin <japhet@chromium.org>
Reviewed-by: Andrey Kosyakov <caseq@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1356139}
This CL enables parsing floats in KVv2's worklet process-side CBOR
parsers. They were already implicitly enabled in the browser-side
parser calls, since those use DataDecoder.
Bug: 333445540
Change-Id: Ib9c590f673c0f5d7e5d0c59b3238825a6ffed732
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5866231
Reviewed-by: Russ Hamilton <behamilton@google.com>
Commit-Queue: mmenke <mmenke@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1356115}
These sensor types are not implemented on any platform. This change
removes them from the Mojo interface to avoid needing to handle the case
of an unsupported sensor type in the browser process.
Some unit tests needed to be rewritten because they were using these
types since they don't limit update frequency or precision.
Change-Id: I7bdd52f1966a7b002f8a28695ec4120118d1c82e
Fixed: 364119459
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5852174
Reviewed-by: Alex Rudenko <alexrudenko@chromium.org>
Commit-Queue: Reilly Grant <reillyg@chromium.org>
Reviewed-by: Raphael Kubo Da Costa <raphael.kubo.da.costa@intel.com>
Cr-Commit-Position: refs/heads/main@{#1356111}
...by making sure to consolidate identical non-k-anon/k-anon bid at
top-level auction as well. Without this consolidation, it's possible
for a non-deterministic top-level scoring version to produce an
outcome where we have a k-anon winner but not a k-anon-is-not-enforced
one, which is strange, and made a DCHECK unhappy.
Bug: 367302752
Change-Id: I78cbacdffe5327feb8cb7a553352ea2cf77aa034
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5866851
Reviewed-by: Russ Hamilton <behamilton@google.com>
Commit-Queue: Maks Orlovich <morlovich@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1356092}
... from USER_VISIBLE to USER_BLOCKING. Not all CacheStorage operations
are super high priority, for example writing is probably not worthy of
USER_BLOCKING. But reading from the cache is very important and is on
the critical path for loading/navigating (i.e. LCP).
This simple change is intended to facilitate Finch experimentation.
Bug: 349939556
Change-Id: I684e81b28b8e98ab0d02508c500f60b014beac9b
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5861674
Commit-Queue: Evan Stade <estade@chromium.org>
Reviewed-by: Ayu Ishii <ayui@chromium.org>
Reviewed-by: Mike Wasserman <msw@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1356057}
This reverts commit 5b0b5b4665.
Reason for revert: b/367166480, b/367250292
Original change's description:
> Make components/crash/core/app a source_set
>
> This is useful in a follow-up CL to ensure deps are not eliminated from
> the components/crash/core/app:app static_library before being linked
> into the final object.
>
> On Windows, components/crash/core/app:app includes declarations in
> crash_export_thunks.h which must have definitions provided by linking
> crash_export_thunks or test_support. This CL corrects missing
> definitions of these crash_export_thunks by linking one of those deps
> or by removing dependencies on components/crash/core/app:app.
>
> Change-Id: I209c11affe4451aa2ea3afd40e065e402bbd2bb2
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3207228
> Reviewed-by: Lei Zhang <thestig@chromium.org>
> Commit-Queue: Joshua Peraza <jperaza@chromium.org>
> Reviewed-by: Andrey Kosyakov <caseq@chromium.org>
> Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#1354830}
Change-Id: I6fbf3110f3d502f3e1098fcea4f597fadb9a41e9
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5866330
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
Reviewed-by: Andrey Kosyakov <caseq@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Lei Zhang <thestig@chromium.org>
Owners-Override: Daniel Yip <danielyip@google.com>
Reviewed-by: Daniel Yip <danielyip@google.com>
Cr-Commit-Position: refs/heads/main@{#1356049}
The flag can be queried like so:
#import "content/public/common/content_features.h"
if (base::FeatureList::IsEnabled(kMacAccessibilityAPIMigration)) {
// Enabled
// ...
} else {
// Disabled
// ...
}
To enable from the command line:
--enable-features=MacAccessibilityAPIMigration
Bug: 363275809
Change-Id: I7ea4de83975decdd15f36571a2ad2cca89b1c499
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5862148
Commit-Queue: Jayson Adams <shrike@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1356026}
Now that blob URL calculations can fully happen on the browser side, we
can compare browser vs renderer origin in all blob cases. One exception
is when we do a same-site RFH swap from the document that registers the
blob URL we're navigating to. In this case the blob URL's origin might
get deleted from the map before the commit finishes, causing the
renderer to think that the origin is opaque. In this case the browser
side has the correct origin, which is used as the precursor for the
renderer's opaque origin. This CL makes us compare the precursor for
this case.
Bug: 888079
Change-Id: I52da40a27457344a588e06305115b57e1597be07
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5860177
Reviewed-by: Nasko Oskov <nasko@chromium.org>
Commit-Queue: Nasko Oskov <nasko@chromium.org>
Auto-Submit: Rakina Zata Amni <rakina@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1356018}
1. When the View is detached from Window
2. When navigating away from _some_ crashed pages, and the early swap
bit is not set.
It's unclear if they can happen in the wild. So far only observed on the
x86 android bots during content_browsertests.
Fixed: 40256003, 366269794
Change-Id: I347093a49989ec7048929ab4553274c2afe5b15c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5858282
Reviewed-by: Vladimir Levin <vmpstr@chromium.org>
Reviewed-by: Ben Kelly <wanderview@chromium.org>
Commit-Queue: William Liu <liuwilliam@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1356001}
Throttle requests to the WebAuthn signal API that can be spammed to
generate sync traffic. At the moment, this is only used in
`signalCurrentUserDetails` since all the other two methods can do is
erase passkeys. Once we implement passkey hiding, we'll throttle those
as well.
Throttling only happens for changes that result in a sync update, so e.g.
signalling a user's name that matches the current name will not consume
quota. Throttling is also disabled for localhost to aid development, and
will not affect the virtual authenticator on any domain.
Quota is keyed per eTLD+1, so accounts.google.com and google.com will
share quota.
Unfortunately, it is not possible to return an error to the site
indicating that throttling happened. Otherwise, that could be used to
determine if a given user has credentials for a site silently. Thus,
throttled requests are dropped silently.
Bug: 361751877
Change-Id: I7695c7670d184e14c93842296d9151006882e859
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5856728
Auto-Submit: Nina Satragno <nsatragno@chromium.org>
Code-Coverage: findit-for-me@appspot.gserviceaccount.com <findit-for-me@appspot.gserviceaccount.com>
Reviewed-by: Victor Vianna <victorvianna@google.com>
Commit-Queue: Adam Langley <agl@chromium.org>
Reviewed-by: Ken Buchanan <kenrb@chromium.org>
Commit-Queue: Nina Satragno <nsatragno@chromium.org>
Reviewed-by: Adam Langley <agl@chromium.org>
Reviewed-by: Arthur Sonzogni <arthursonzogni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1355972}
The check for frame_ was accidentally flipped in this refactor:
2827c75415.
A lot of the WPTs this bug was causing to fail are still failing because
they haven't been run in a long time. These will be fixed in follow up
CLs.
Bug: 346991169
Change-Id: I865e379f2048ecfaf044dd9467c53af2ef381b07
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5837824
Reviewed-by: Christine Hollingsworth <christinesm@chromium.org>
Reviewed-by: danakj <danakj@chromium.org>
Commit-Queue: Nathan Memmott <memmott@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1355953}
This is a reland of commit 33a5413a21
The original CL causes test failures, because `mInternalsHolder` is null
inside `WebContentsImpl#getViewAndroidDelegate`.
Why `mInternalsHolder` is null is unclear, as the stack trace doesn't
provide much information about the original call site for the creation
of the tab and about why the tab's `WebContents` has a null
`mInternalsHolder`.
Stack trace: https://paste.googleplex.com/5449631275417600
This CL adds a null check to `mInternalsHolder`, with the promise to
immediately start investigating the root cause of the problem and fix it
if necessary. The null check is a temporary fix, so that we can start
experimenting with the feature in M130.
The failures caused by the original CL:
https://ci.chromium.org/ui/p/chromium/builders/ci/android-15-x64-rel/2581
Original change's description:
> Add fieldtrial config for the Sensitive Content feature
>
> Bug: 343119998
> Change-Id: I4c7fa55645bf034e10b504f802906581721a74b9
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5860616
> Reviewed-by: Jan Keitel <jkeitel@google.com>
> Commit-Queue: Theo Cristea <theocristea@google.com>
> Cr-Commit-Position: refs/heads/main@{#1355158}
Bug: 343119998
Change-Id: Idb3e026506a62183e8b4e5b759dd1bd1fb49081c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5865369
Reviewed-by: Jinsuk Kim <jinsukkim@chromium.org>
Commit-Queue: Theo Cristea <theocristea@google.com>
Cr-Commit-Position: refs/heads/main@{#1355854}
Callback
This CL adds the "prefetch started" browser callback that is called
once the prefetch request initially kicks off. This callback is not
called at all for any redirects caused by the initial prefetch.
WebView will use this callback to resolve the `Future` returned
by the application's call to start the prefetch via. the WebView
prefetch API.
Bug: 363946909
Change-Id: I03c68418c401dce53b692a39510ad246bb81ddb5
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5829415
Reviewed-by: Kouhei Ueno <kouhei@chromium.org>
Commit-Queue: Wayne Jackson Jr. <wbjacksonjr@chromium.org>
Reviewed-by: Hiroshige Hayashizaki <hiroshige@chromium.org>
Reviewed-by: Rakina Zata Amni <rakina@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1355842}
Element count was used in attempt to reduce the number of
display:inline-block elements that are included in the tree.
The optimization does not affect behavior, but led to flakiness
because the page load can pause in the middle of the parent.
The optimization is likely unnecessary complexity -- web content
does not typically use display:inline-block.
Bug: 365027678
Change-Id: Idbfacb42ab9aa7332dc916c4e7dfcc4764aea259
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5859350
Auto-Submit: Aaron Leventhal <aleventhal@chromium.org>
Reviewed-by: Mark Schillaci <mschillaci@google.com>
Commit-Queue: Aaron Leventhal <aleventhal@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1355832}
ByteBuffer#{get, put} work on the current ByteBuffer#position(): writing a single byte will put it as "position" within the ByteBuffer, then increment position by one (read does the same but returns the byte instead of writing it). As such, the native layer should do the same: if we're reading from a ByteBuffer in native, we should read the same way Java would; from position, until limit.
I'm not sure if this is an existing issue within Chrome (maybe all ByteBuffers there ends up always having position == 0 and limit == size), but extending MaybeJavaByteBufferToMutableSpan to take this into account would allow Cronet to make use of these utilities.
Note: There is no JNI function to directly fetch the position and limit of a ByteBuffer (like one can do for data and size). As such, we need
to tell jni_zero to generate bindings for ByteBuffer.
Bug: 41488662, b:358568022
Change-Id: I38eb668af549ce73de4157816510cb287eae5945
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5776110
Owners-Override: Andrew Grieve <agrieve@chromium.org>
Commit-Queue: Stefano Duo <stefanoduo@google.com>
Reviewed-by: Etienne Dechamps <edechamps@google.com>
Reviewed-by: Andrew Grieve <agrieve@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1355831}
FencedFramesLocalUnpartitionedDataAccess is disabled.
The current error message when fenced frame feature is on but
FencedFramesLocalUnpartitionedDataAccess feature is off, and shared
storage get is called in a fenced frame:
"Cannot call get() outside of a fenced frame."
This is confusing because the call did happen in a fenced frame.
Change it to explain that the failure is due to the local unpartitioned
data access feature is off.
Bug: 324440086
Change-Id: Ic8e29c994f6abba851f031a2263cbec171eb957c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5854088
Reviewed-by: Liam Brady <lbrady@google.com>
Commit-Queue: Xiaochen Zhou <xiaochenzh@chromium.org>
Reviewed-by: Yao Xiao <yaoxia@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1355785}
We should never reload the policies of an error page from history,
since that might end up taking precedence over stricter policies
inherited from the parent/initiator.
Bug: 364773822
Change-Id: I903dd11d8f7e771e1f8bc9dc640690da92d61177
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5860536
Reviewed-by: Charlie Reis <creis@chromium.org>
Commit-Queue: Antonio Sartori <antoniosartori@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1355730}
Without this the browser is crashing when
`window.open("", "_blank", "popin")` is called.
Error message: FrameHost::CreateNewWindowCallback was destroyed without
first either being run or its corresponding binding being closed.
Calling `ReportBadMessage()` on `frame_host_associated_receiver_ ` is
crashing the renderer as expected but keeps the browser alive.
In addition to this, in a followup CL, we will fix the renderer-side
check to fail on "" url or open about:blank like regular popups do.
Bug: 340606651
Change-Id: I18c9d1b1472e4debcd0f0a0167bb9d5c90cafce8
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5854463
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Commit-Queue: Sandor «Alex» Major <sandormajor@google.com>
Auto-Submit: Sandor «Alex» Major <sandormajor@google.com>
Reviewed-by: Ari Chivukula <arichiv@chromium.org>
Reviewed-by: Nasko Oskov <nasko@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1355696}
Duplicate navigations are navigations that are the same as the
current ongoing navigations, and likely to be triggered accidentally
by e.g. double link/button clicks. This CL makes it so that we
record duplicate navs as a separate NavigationDiscardReason.
Also, currently when a new renderer-initiated navigation is
triggered while there is already another navigation initiated by
the same renderer ongoing, the older navigation is canceled by
overwriting the NavigationClient. This cancellation is incorrectly
marked as kInternalCancellation because the overwrite didn't
set a reason. This CL fixes that by setting the reason to
indicate that the navigation client is disconnected because of
a new navigation / duplicate navigation. This CL also makes
form submission-initiated cancellation mark the disconnection
correctly (as "new navigation").
Bug: 366060351
Change-Id: I084ca4dbd56805192cf4d553ab866e011d7d1917
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5856745
Reviewed-by: Takashi Toyoshima <toyoshim@chromium.org>
Commit-Queue: Rakina Zata Amni <rakina@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1355642}
The TrustedSignalsCacheImpl puts together partitions only immediately
before starting a fetch. The TrustedSignalsFetcher immediately uses them
to create a request body, and then never needs them again. As a result,
there's no need to create copies, as the code was previously doing, to
store in the short-lived Bidding/Scoring Partition structs.
Bug: 333445540
Change-Id: Idfc9daa963af0e3b7fb5731dd1225ae4e5db5706
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5860259
Reviewed-by: Russ Hamilton <behamilton@google.com>
Commit-Queue: mmenke <mmenke@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1355564}
Takes fDO reports from B&A servers, and collect/send them on Chrome
side. Also updates lockout/cooldown with server's fDO reports.
Bug: b/356872513
Change-Id: Icbb4af8c6ff901bb08cbbff2b4b9dbea52370986
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5769675
Commit-Queue: Qingxin Wu <qingxinwu@google.com>
Reviewed-by: Russ Hamilton <behamilton@google.com>
Cr-Commit-Position: refs/heads/main@{#1355525}
Embedders like WebView can prevent same-site RFH swaps through returning
false in ShouldAllowSameSiteRenderFrameHostChange(). This is so that
RenderDocument-subframe can be enabled by default except for WebView.
However, the check is currently too powerful and prevents RFH swaps
on crashed frames as well. This CL makes it so that even when
embedders return false, must_be_replaced() RFHs will still be replaced,
so navigating from crashed frames will still change RFHs.
Bug: 936696
Change-Id: I2f98b4018c8df3b3a03a15044ab03658a395ebb2
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5859500
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Auto-Submit: Rakina Zata Amni <rakina@chromium.org>
Commit-Queue: Rakina Zata Amni <rakina@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1355477}
