It makes more sense to have a default of kCrossSite and only use
kSameSite when the storage key is actually first-party. This will allow
construction logic to simplify when I followup and reduce the amount of
methods available.
Bug: 1410254
Change-Id: I02dfc4ee431b17bf0c53929409d6ca59e0fa27dd
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4225216
Commit-Queue: Ari Chivukula <arichiv@chromium.org>
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Reviewed-by: Nate Chapin <japhet@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1103310}
Cloning could fail if the file's underlying file system does not support
copy-on-write, such as when accessing FAT formatted external USB drives
(which do not support copy-on-write) from a Mac (which otherwise does)
Adds a number of unit tests, since this cloning was accidentally
completely uncovered by automated tests. Whoops.
Bug: 1413443
Change-Id: I28f742e1da99fc5e2e923074f2ab571742b5ffb4
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4229137
Reviewed-by: Daseul Lee <dslee@chromium.org>
Commit-Queue: Austin Sullivan <asully@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1103307}
When a user is auto signed-in and logs out to switch the account being
used, they might run into a deadloop where they are auto signed-in into
the same account again. We add a 10 minute cooldown which starts from
the time a user is auto signed-in. Within the cooldown, the user will be
able to sign-in explicitly through choosing an account on the dialog.
The cooldown time will be subject to change as we have yet to gather
metrics to validate if 10 minutes is ideal.
Bug: 1408533
Change-Id: Ic3323d5f638cc0c21124b6561131b8b874350639
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4216231
Reviewed-by: Dominick Ng <dominickn@chromium.org>
Reviewed-by: Alexander Timin <altimin@chromium.org>
Reviewed-by: Yi Gu <yigu@chromium.org>
Commit-Queue: Zachary Tan <tanzachary@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1103248}
On macOS, this disables loading 3rd-party DAL plugins, which may
crash upon use.
This relies on the hardened runtime from signed binaries.
When the CHILD_PLUGIN option is passed, the runtime is disabled and
3rd-party DAL plugins are allowed.
For developers convenience who cannot sign their binaries,
an environment variable was identified within the the macOS libraries
to achieve a similar effect and skip loading all DAL plugins.
This is enabled by the RetryGetVideoCaptureDeviceInfos feature which
is also updated accordingly.
The feature can now handle a service crash properly and is compiled
on all platforms, though only macOS will have at most one retry.
On the second attempt, the VideoCaptureService safe-mode will be
enabled.
Traces of the old RetryCount are removed since the value is unused.
Bug: 990381
Change-Id: If042b19006ef4166260941af5485897f65e5e0de
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4209899
Reviewed-by: Arthur Sonzogni <arthursonzogni@chromium.org>
Commit-Queue: Florent Castelli <orphis@chromium.org>
Reviewed-by: Alexander Alekseev <alemate@chromium.org>
Reviewed-by: Tony Herre <toprice@chromium.org>
Reviewed-by: Henrik Boström <hbos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1103243}
DRM_MODE_CONNECTOR_VIRTUAL has been treated as internal to test tablet
features inside Chrome OS VM. But it also prevents display resolution
from being changed. The new flag --drm-virtual-connector-is-external
added in this CL will treat virtual displays as external, making it
possible to test display resolution change in VM testing.
Bug: b:266527483
Test: Change display resolution in CrOS VM with vkms or virtio_gpu
Change-Id: I83fdefed8b57cda016a6cd6fbbbd476fa6a7209f
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4190424
Commit-Queue: Yi Xie <yixie@chromium.org>
Reviewed-by: Scott Violet <sky@chromium.org>
Reviewed-by: Bo Liu <boliu@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1103145}
This CL adds the mechanism to save the chekcsum hash strings of service
worker scripts, which are calculated while the service worker update
check process. After this CL, if the user has the service worker script
info in the database and its |sha256_checksum| is empty, the update
checker returns the sha256 checksums for both main and sub scripts,
regardless of the update check result.
Once the update check finished, the browser tries to update the script
resource list and store it to the database with the newly calculated
checksums.
We don't update the service worker version since the only updated thing
is the |sha256_checksum| record in DB and that is no user visible
change. However, this decision introduced more code changes, so using
`StoreRegistration`, or adding the option not to create the new version
to `StoreRegistration` may be another good option, at least in terms of
the code complexitiy. Feedback is welcomed.
Bug: 1371756
Change-Id: Ie4cf2033c0f06407e41e7d35fae048ce9741877c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4210875
Reviewed-by: Kouhei Ueno <kouhei@chromium.org>
Reviewed-by: Hiroki Nakagawa <nhiroki@chromium.org>
Reviewed-by: Yoshisato Yanagisawa <yyanagisawa@chromium.org>
Reviewed-by: Takashi Toyoshima <toyoshim@chromium.org>
Commit-Queue: Shunya Shishido <sisidovski@chromium.org>
Reviewed-by: Minoru Chikamune <chikamune@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1103144}
A follow-up CL to the service worker sha256 checksum browsertests.
Currently checksum browsertests are written in
`Sha256ScriptChecksum_ImportScripts` and
`Sha256ScriptChecksum_StaticImport`. But the current test coverage is
not enough since we don't test the following scenarios:
1. Both main and imported scripts are updated.
2. Main script is updated, but imported script is not.
3. Imported script is updated, but main script is not.
Also, above casees should be covered in both `ImportScripts` and
`StaticImport` tests. In addition to them, we cover the case when both
main and imported scripts are not updated (this case is already
covered).
As a result, we should cover 8 below cases.
- main(changed or not changed)
- imported(changed or not changed)
- script-type(classic or module)
This CL addresses the review comments in
https://chromium-review.googlesource.com/c/chromium/src/+/4172667/comment/01d97888_d5d02666/
Bug: 1371756, 1409787
Change-Id: Id29a1e072de001eddfd8527e7b0c05a153b35fbf
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4231052
Reviewed-by: Hiroki Nakagawa <nhiroki@chromium.org>
Commit-Queue: Shunya Shishido <sisidovski@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1103118}
This more closely mimics the firebase bug we are seeking to mitigate
with the deprecation trial.
This fixes a bug where we de-registered the origin based on whether the
iframe had the OT token included. This logic is incorrect, as we should
be taking the 'word' of the page when it's first party only.
Bug: 1399319
Change-Id: Iba20f004fa9c35e17c5f445bf99378f04ea1f984
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4232870
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Auto-Submit: Ari Chivukula <arichiv@chromium.org>
Commit-Queue: Ari Chivukula <arichiv@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1103088}
Adds the clang-coverage/no-clang-coverage tag pair to the GPU
integration test harness. The former is added if the browser is
compiled with use_clang_coverage=true, otherwise the latter is added.
In practice, this should mean that the former is added when run from coverage bots but not anywhere else.
Bug: 1413845
Change-Id: I1949e853e172d3d3c2b74a64fe5b67de758ace72
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4228121
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Reviewed-by: Kai Ninomiya <kainino@chromium.org>
Commit-Queue: Brian Sheedy <bsheedy@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1103044}
Currently ServiceWorkerNetworkProviderForFrame::CreateURLLoader() in the
content layer is called to create a WebURLLoader from
blink::LoaderFactoryForFrame::CreateURLLoader().
We'd like to stop exposing blink::WebURLLoader to the content layer.
So this CL does the followings:
- Replace ServiceWorkerNetworkProviderForFrame::CreateURLLoader() with
GetSubresourceLoaderFactory() which returns a
network::SharedURLLoaderFactory.
- Make blink::LoaderFactoryForFrame::CreateURLLoader() call the new
method to get a network::SharedURLLoaderFactory, and create a
blink::WebURLLoaderFactory using Platform::WrapURLLoaderFactory().
- Introduce Platform::WrapURLLoaderFactory(
scoped_refptr<network::SharedURLLoaderFactory>).
This CL should not introduce any behavior change.
Bug: 1413912, 789857
Change-Id: I44343eaceda6d308924db5bc75de8385ec01c4c9
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4211117
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Reviewed-by: Hiroki Nakagawa <nhiroki@chromium.org>
Commit-Queue: Tsuyoshi Horo <horo@chromium.org>
Reviewed-by: Yoshisato Yanagisawa <yyanagisawa@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1102996}
This is a precursor CL before forbidding access to
`ui::Cursor::image_scale_factor()` for non-custom cursors.
Update TouchEmulatorTest.CursorScaleFactor to not check the scale factor
when it's disabled, and instead just check that a regular pointer cursor
is used.
Additionally, TouchEmulator is updated to simplify the code to load its
custom cursor.
Bug: 1149906
Change-Id: Ic44dc5d3975047240f66ce73183ee110a79a8aba
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4215436
Reviewed-by: David Bokan <bokan@chromium.org>
Code-Coverage: Findit <findit-for-me@appspot.gserviceaccount.com>
Commit-Queue: Henrique Ferreiro <hferreiro@igalia.com>
Cr-Commit-Position: refs/heads/main@{#1102991}
The combination of existing unit test coverage for the exact DB schema
and these new static asserts ensures that the DB version number is
updated properly without the need for a noisy presubmit.
Change-Id: I206a4da41bcd57e6fea2687e8e0d68caadb904f5
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4232359
Reviewed-by: Charlie Harrison <csharrison@chromium.org>
Quick-Run: Andrew Paseltiner <apaseltiner@chromium.org>
Commit-Queue: Andrew Paseltiner <apaseltiner@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1102983}
MSDN documentation says UiaRaiseActiveTextPositionChangedEvent is
supported in Win8.1 onwards, but it turns out that some Win10 versions
of uiautomationcore.dll don't have it. Adding comment to code so no one
else tries to remove the dynamic function call.
Bug: 1408307, 1413076
Change-Id: If1e54feae9dd05873018effe6577612edb4ae75d
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4234082
Commit-Queue: David Bienvenu <davidbienvenu@chromium.org>
Reviewed-by: Katie Dektar <katie@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1102982}
1) Small sandbox change to only add log file rules in one place so
the gpu process only gets a rule once.
2) Sandbox now gets to assume log files are absolute paths, because
the logging infrastructure in logging_chrome.cc now ensures an
absolute path is provided (on Windows).
3) The gpu process would choke in a non-obvious way if a
'--log-file=foo.log' was provided. This now results in the default
log file being used (and an error message).
4) Other invalid paths such as --log-file=.\out\foo.log now turn
into the default chrome_debug.log in all processes - this is probably
more helpful than crashing or only logging in half of the cases.
Tests are updated to expect absolute paths on Windows.
Bug: 1402641
Change-Id: I5177e7b89eca5daafacd4b6b92d7225ab53b4052
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4153432
Commit-Queue: Alex Gough <ajgo@chromium.org>
Reviewed-by: Will Harris <wfh@chromium.org>
Reviewed-by: David Bienvenu <davidbienvenu@chromium.org>
Reviewed-by: David Roger <droger@chromium.org>
Reviewed-by: Zhenyao Mo <zmo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1102980}
Follow-up to https://crrev.com/c/4122683
This fixes the getUniqueId method, which relies on existence checks in
a map of FileSystemURLs that would incorrectly fail for files differing
by only the nonce of their FileSystemURL's opaque origin.
Bug: 1342961, 1396116
Change-Id: I3fb704560b8a86090feed725c4802a2f2a6f004d
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4225992
Commit-Queue: Austin Sullivan <asully@chromium.org>
Reviewed-by: Marijn Kruisselbrink <mek@chromium.org>
Commit-Queue: Marijn Kruisselbrink <mek@chromium.org>
Auto-Submit: Austin Sullivan <asully@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1102919}
Given the exploration done in crbug.com/1297030, we found that
RFHI::agent_scheduling_group_ being a SafeRef protected against possible
UaFs where Render*Impl objects can live longer than
RenderProcessHostImpl/AgentSchedulingGroupHost, and the suggested we
landed on was that we should keep this member a SafeRef to ensure
further protection.
Change-Id: Icdd6401dfa8800a60d0c3b66ab347ca45c32ece2
Bug: 1297030
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4226418
Reviewed-by: Łukasz Anforowicz <lukasza@chromium.org>
Reviewed-by: Charlie Reis <creis@chromium.org>
Commit-Queue: Dominic Farolino <dom@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1102872}
Currently, NavigationThrottles attach only when a URLRequest will be
created, allowing throttles to participate in the network request
portion of a navigation. However, for navigations that will immedaitely
commit because no URLRequest is needed, it is impossible to throttle
the navigation. Navigations that immediately commit include
about:blank, about:srcdoc, and most* (see below) same document
navigations.
This CL introduces a new NavigationThrottle callback,
WillCommitWithoutUrlLoader. WillCommitWithoutUrlLoader is called only
in the immediate commit case (when no other NavigationThrottle
callbacks will be called), and allows the NavigationThrottle to defer
or cancel the navigation, as any other callback does.
Currently, no NavigationThrottles use WillCommitWithoutUrlLoader, but
it will be used by a new throttle that will be introduced in
https://chromium-review.googlesource.com/c/chromium/src/+/4092862.
* Some same document navigations are committed synchronously in the
renderer process, and the browser process is only told about the navigation after the fact, so we can't throttle them. Those
navigations are renderer-initiated non-back-forward same-document
navigations. WillCommitWithoutUrlLoader can intercept all
browser-initiated same-document navigations, as well as
renderer-initiated back-forward same-document navigations.
Bug: 1067613, 1371580
Change-Id: I7066e69bee5e891c9aec1b79c8c266e011f726ea
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4210858
Commit-Queue: Nate Chapin <japhet@chromium.org>
Reviewed-by: Arthur Sonzogni <arthursonzogni@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1102862}
There is nothing in our code preventing from running the default action
on an accessibility node, even when that node has the kNone default
action set. Some ATs even relied on this behavior.
We add a DCHECK so we can detect cases when this is happening, address
them individually, and finally stop exposing default actions on nodes
that haven't them.
Bug: 1370076, 1379347, 1382034
Change-Id: I75e08867695f61d1358dc9855a446d971f748516
AX-relnotes: no user-facing changes.
Cq-Include-Trybots: luci.chromium.try:linux-blink-web-tests-force-accessibility-rel
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4098912
Reviewed-by: Aaron Leventhal <aleventhal@chromium.org>
Commit-Queue: Jacobo Aragunde Pérez <jaragunde@igalia.com>
Cr-Commit-Position: refs/heads/main@{#1102815}
Previously, the AdAuctionServiceImpl would wait until the
InterestGroupAuctionReporter was complete, and only then pass ad
beacon maps to the FencedFrameReporter, which fenced frames use to
trigger event-based requests.
This CL moves those calls into InterestGroupAuctionReporter, which now
also builds the FencedFrameReporter. The calls are also made as soon
as each reporting script is complete, so that beacons are sent earlier.
Bug: 1410791
Change-Id: I42335aaa783cbeb14c361aba22b0d6d68ab8df3c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4226651
Commit-Queue: Matt Menke <mmenke@chromium.org>
Reviewed-by: Maks Orlovich <morlovich@chromium.org>
Reviewed-by: Shivani Sharma <shivanisha@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1102814}
Okay so hear me out. I know it looks like we're losing a bunch of type
safety, and we are, but in trade the codegen will go a lot smoother.
Once we codegen the path and translates a WebFeature into a deprecation
message, we won't need the two independent DeprecationIssueType enums
just to make sure the manual code path is clean. A generated codepath
can just pass around a string and it'll be okay. If this was just c++
code we might want to generate and keep the enum, but since we need to
pass this into browser_protocol.pdl trying to track an enum would just
make things confusing. As for the preference_api.cc codepath, that seems
like a one-off and we can treat it as such until we have a second
consumer. At that point we might want to formalize the codegen for that
path too.
TL;DR once we get to step 6 this will all get a lot cleaner, the mess of
strings is temporary.
This CL is part of a series:
(1) Add deprecation.json5 file
(2) Add existing deprecations to deprecation.json5
(3) Copy deprecation.json5 into devtools_frontend via update flow
(4) Update README to reflect devtools codegen
(5) Replace browser_protocol.pdl enum
(6) Codegen c++ code
Bug: 1411444
Change-Id: I1bb3882f3bf50b76879cad30c340f90d9687a73a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4226621
Reviewed-by: Danil Somsikov <dsv@chromium.org>
Reviewed-by: Joe Mason <joenotcharles@google.com>
Code-Coverage: Findit <findit-for-me@appspot.gserviceaccount.com>
Reviewed-by: Andrey Kosyakov <caseq@chromium.org>
Commit-Queue: Ari Chivukula <arichiv@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1102747}
This is a follow-up CL for the parent CL[1] and the discussion in the
other previous CL[2]. Currently the checksum can be updated twice, and
it hits DCHECK when ServiceWorkerCacheWriter runs with the
ChecksumUpdateTiming::kAlways option and there is an update in SW
scripts.
Specifically, that case would go with the following scenario.
1) SW resources are stored, but sha256 checksums in the database are
empty.
2) The update check runs with the ChecksumUpdateTiming::kAlways option to
update the sha256 checksum.
3) ServiceWorkerCacheWriter finds a difference between cached data and
data from the network, then checksum->Update is called twice in
`MaybeWriteData` and `WriteDataToResponseWriter`.
4) ServiceWorkerCacheWriter instance is moved and `GetSha256Checksum` is
called from ServiceWorkerUpdatedScriptLoader.
To solve this issue, this CL adds 1) the if statement to
`WriteDataToResponseWriter` to call checksum->Update only when
`ChecksumUpdateTiming` is `kCacheMismatch`. 2) delete the
ChecksumUpdateTiming DCHECK in `ServiceWorkerUpdatedScriptLoader` since
it can be both enum values. 3) unittest to check this scenario.
[1] crrev.com/c/4209712
[2] https://chromium-review.googlesource.com/c/chromium/src/+/4210872/comment/8d9915da_7b2be08d/
Bug: 1371756
Change-Id: I2ef0fa1a703a5a31690201174b42c6df68317ce5
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4227397
Reviewed-by: Yoshisato Yanagisawa <yyanagisawa@chromium.org>
Reviewed-by: Hiroki Nakagawa <nhiroki@chromium.org>
Commit-Queue: Shunya Shishido <sisidovski@chromium.org>
Reviewed-by: Minoru Chikamune <chikamune@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1102720}
This CL will expose an option to return calculated sha256 checksums from
ServiceWorkerUpdateChecker. This internally uses the
ChecksumUpdateTiming::kAlways option in ServiceWorkerCacheWriter and
return checksums if the update check result is kIdentical.
ServiceWorkerUpdateChecker manages multiple checksums generated by each
script.
In this CL returned checksums are still not used, it will be handled by
the follow-up CL.
Bug: 1371756
Change-Id: I7472eb7191d28784680fe853477e1802d6b0bd5f
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4209712
Reviewed-by: Minoru Chikamune <chikamune@chromium.org>
Reviewed-by: Hiroki Nakagawa <nhiroki@chromium.org>
Reviewed-by: Yoshisato Yanagisawa <yyanagisawa@chromium.org>
Commit-Queue: Shunya Shishido <sisidovski@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1102716}
