This moves the keepalive behaviour that was previously on
PolicyContainerHost to a separate NavigationStateKeepAlive class. The
Blink mirror mojo remote mechanism remains the same, but the definitions
have moved.
There is now one mojo UniqueReceiverSet per storage partition.
Previously, there was one per PolicyContainerHost (and thus
RenderFrameHost). This UniqueReceiverSet can have receivers for multiple
RenderFrameHosts, and multiple receivers per RenderFrameHost (e.g., for
multiple queued navigations).
behaviour change
Test: Covered by NavigationBrowserTest.FormSubmission* tests, minimal
Bug: 323753235
Change-Id: If120e495c228d687e3624d53344e72b5e8cacbeb
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5278216
Reviewed-by: Charlie Reis <creis@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Antonio Sartori <antoniosartori@chromium.org>
Commit-Queue: Sharon Yang <yangsharon@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1269131}
As part of the effort to integrate the CdmStorageDatabase with the
BrowsingDataModel, we add an interface CdmStorageDataModel to expose
functions that are requisite in the integration with BrowsingDataModel.
Implementation will be done in another CL.
Bug: 1454512
Change-Id: I848a9d9610a68026bde6c3a5e10d5588af2c1ba6
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5296881
Commit-Queue: Vikram Pasupathy <vpasupathy@chromium.org>
Reviewed-by: John Rummell <jrummell@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Reviewed-by: Bo Liu <boliu@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1263755}
To simplify the code, this CL merges `URLLoaderInterceptor`'s
`BrowserProcessWrapper`, `RenderProcessHostWrapper` and
`URLLoaderFactoryNavigationWrapper` into a single `Wrapper`.
This CL also migrates related callbacks to use
`network::URLLoaderFactoryBuilder`.
Bug: 1506871
Change-Id: I91111bfb9c9e45a3c26a515789c967ff24e8661e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5148395
Reviewed-by: Lingqi Chi <lingqi@chromium.org>
Reviewed-by: Hiroki Nakagawa <nhiroki@chromium.org>
Reviewed-by: Arthur Sonzogni <arthursonzogni@chromium.org>
Commit-Queue: Hiroshige Hayashizaki <hiroshige@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1253091}
This CL is a refactor with no intended behavior change.
This CL replaces SSLClientAuthHandler::ContextGetter with base::WeakPtr.
This CL makes URLLoaderNetworkContext private. This CL deletes
now-unnecessary wrapper functions GetContextFromStoragePartition and
GetBrowserContextFromStoragePartition.
Bug: 1371177
Change-Id: I4bc5c43be8933dc5337f0e38004d69747d0d5957
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5214875
Reviewed-by: Devlin Cronin <rdevlin.cronin@chromium.org>
Commit-Queue: Erik Chen <erikchen@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1251234}
This CL is a refactor with no intended behavior change.
This CL replaces usage of web_contents_getter and browser_context_getter
with WeakPtrs in several content classes. This removes several potential
sources of UaFs.
Change-Id: I831c3f51730386146433726ce5f3efba08288616
Bug: 1371177
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5208248
Reviewed-by: Devlin Cronin <rdevlin.cronin@chromium.org>
Commit-Queue: Erik Chen <erikchen@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1249178}
A new schema is introduced into CdmStorageDatabase to add last_modified
and file_size to be able to support time-based deletion and time-based
usage calculation.
Methods were implemented to delete by time frame, by storage key, and
to calculate file size using SQL queries for time frames by storing
the file size into the CdmStorageDatabase to be a one time operation.
This CL also provides the functionality that automatically deletes the
database if a Delete function for a subset (i.e file, storage key,
time-frame) ends up removing entries such that there are no more entries
in the database.
An SQL statement is used to alter the version1 database so that we don't
run into crashes when a user that already has the CdmStorageDatabase
v1.0 in their profile runs into queries that are made for the v2.0, such
as writing into the column file_size, since file_size is only in v2.0.
Testing: unittests +
Manual Testing Steps for the Schema Alter code:
1. Build chrome on main branch.
2. Go to chrome://flags and enable kCdmStorageDatabase and
kCdmStorageDatabaseMigration.
3. Open a new profile, name it CdmStorageDatabase (or anything you want)
4. Play this website: https://integration.staging.widevine.com/player?contentUrl=https://storage.googleapis.com/wvtemp/hmchen/poc/tears_hd_cenc.mpd&proxyServerUrl=https://proxy.uat.widevine.com/proxy?video_id=GTS_CAN_PLAY_CLIENT_TOKEN%26provider=widevine_test%26full_response=true&persistentStateRequired=true
5. Log the kVersionNumber (should be 1) (I did this through LOG(ERROR)).
6. A value should be written.
7. Quit Chrome.
8. Switch your branch to these changes using git and build chrome.
9. Open chrome, verify the same flags are still enabled, and open
the same profile you used as before.
10. Play same website as step #4.
11. log the kVersionNumber (should be 2) (I did this through LOG(ERROR))
12. View in chrome://histograms/Media.EME that the
IncompatibleDatabaseDetected histogram was triggered.
13. Verify that playback plays continuously and Chrome does not crash.
OBSOLETE_HISTOGRAMS= Media.EME.CdmStorageManager.DeleteDatabaseError.Incognito, Media.EME.CdmStorageManager.DeleteDatabaseError.NonIncognito.
Bug: 1454512
Change-Id: I64f9dff580114545ececf5d7b4f03124b1f55192
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4994868
Reviewed-by: Evan Stade <estade@chromium.org>
Reviewed-by: Evan Liu <evliu@google.com>
Reviewed-by: John Rummell <jrummell@chromium.org>
Commit-Queue: Vikram Pasupathy <vpasupathy@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1242731}
Recorded only for requests where a 3pcd facilitated testing is enabled
(the client is part of the experiment and the profile is not guest or
incognito).
The metrics records:
- `kSet` if the `Sec-Cookie-Deprecation` header is added to the request.
- `kNoLabel` if there is no label available. This happens when the
client is ineligible to the experiment or when the label value
configured in the experiment is empty ""
-`kNoCookie` if there is a label available but the opt-in cookie is not
available.
Change-Id: I2c1d533335f0d0e817109481510cedb4199208bc
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5115112
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Reviewed-by: Kenichi Ishibashi <bashi@chromium.org>
Commit-Queue: Anthony Garant <anthonygarant@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1242406}
We pay down some tech debt by adding a browser-side
`PermissionsPolicy` check for the
`blink::mojom::PermissionsPolicyFeature::kSharedStorage` feature
in the cases where the initial check was done by the renderer.
For the iframe navigation case, however, since the initial
permissions policy check for shared storage writing from an iframe
navigation request already occurs in the browser process in
`NavigationRequest`, it's not absolutely necessary to do a double
check, and so if we are unable to perform one due to not being able
to obtain the parent policy, we skip the check and proceed with the
operation(s). Whereas, in non-navigation-initiated cases, if we are
unable to perform the check, we drop any operation(s).
While we're at it, we pass in the `NavigationOrDocumentHandle` to
`SharedStorageHeaderObserver::HeaderReceived()` instead of the
`RenderFrameHost`, and add a method
`NavigationOrDocumentHandle::GetTopFrameOrigin()`, to try to avoid
having to create a new opaque origin for the user profile preferences
check in the case when a `RenderFrameHost` is not available to help us
access the main frame's last committed origin.
We also add a couple of metrics related to the above.
Note that in "SharedStorageHeaderObserverTest", we swap out the
`ContentBrowserClient` for a derived `MockContentBrowserClient`
instance to control the return value of
`MockContentBrowserClient::IsSharedStorageAllowed()`.
Bug: 1434529,1218540
Change-Id: I7020626511215bbfc1972e6a3fddef5432b95cd1
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4944272
Reviewed-by: Nasko Oskov <nasko@chromium.org>
Reviewed-by: Yao Xiao <yaoxia@chromium.org>
Commit-Queue: Cammie Smith Barnes <cammie@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1239898}
Change the raw_ptr to the KAnonymityServiceDelegate to instead use a
repeating callback. This ensures the InterestGroupKAnonymity Manager
cannot reference the pointer after it has been freed.
Bug: 1506985
Change-Id: I1e2f99822d6063a0c76e887e25dddaabb0ef551c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5083205
Reviewed-by: Caleb Raitto <caraitto@chromium.org>
Commit-Queue: Ayu Ishii <ayui@chromium.org>
Reviewed-by: Ayu Ishii <ayui@chromium.org>
Auto-Submit: Russ Hamilton <behamilton@google.com>
Cr-Commit-Position: refs/heads/main@{#1233038}
IndexedDBControlWrapper was an IndexedDBControl implementation that
simply passed through all operations to an underlying IndexedDBControl
(IndexedDBContextImpl). The only functionality that it added was to
interact with the SpecialStoragePolicy whenever a new IndexedDBFactory
connection is established.
It's simpler and more idiomatic to accomplish this by being an
observer of the underlying IndexedDBContextImpl rather intercepting
messages meant for the IndexedDBContextImpl. Luckily, such an observer
interface already exists.
Bug: 717812
Change-Id: If7adf390cb34dc52e35fa4a27983f3d8a283fb00
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5069675
Reviewed-by: Nathan Memmott <memmott@chromium.org>
Commit-Queue: Evan Stade <estade@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1231011}
This reverts commit 0e675843e1.
Reason for revert: this is causing some crashes, most likely due to
async OTR profile deletion.
Original change's description:
> StoragePartition: Move shutdown to OnBrowserContextWillBeDestroyed
>
> Follow-up from crrev.com/c/4869214. This moves shutting down of
> services in ~StoragePartitionImpl to OnBrowserContextWillBeDestroyed.
> Doing this earlier will prevent other dangling pointer issues related
> to browser context (including fixing one in StoragePartitionImpl), and
> it consolidates shutdown.
>
> Bug: 1492282
> Change-Id: I57e1e439ad715df6625ef011c1a99a76051fac2e
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4968658
> Commit-Queue: Scott Haseley <shaseley@chromium.org>
> Reviewed-by: Ayu Ishii <ayui@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#1215818}
Bug: 1492282, 1497693
Change-Id: Id8b4fdc3989299886caa13277d1b7311cef79007
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4990213
Reviewed-by: Ayu Ishii <ayui@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Scott Haseley <shaseley@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1217729}
Follow-up from crrev.com/c/4869214. This moves shutting down of
services in ~StoragePartitionImpl to OnBrowserContextWillBeDestroyed.
Doing this earlier will prevent other dangling pointer issues related
to browser context (including fixing one in StoragePartitionImpl), and
it consolidates shutdown.
Bug: 1492282
Change-Id: I57e1e439ad715df6625ef011c1a99a76051fac2e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4968658
Commit-Queue: Scott Haseley <shaseley@chromium.org>
Reviewed-by: Ayu Ishii <ayui@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1215818}
Follow-up from crrev.com/c/4869214. This moves shutting down of
ServiceWorkerContext and SharedWorkerService from
BrowserContextImpl::NotifyWillBeDestroyed to
StoragePartitionImpl::OnBrowserContextWillBeDestroyed.
Bug: 1492282
Change-Id: I74b8c88540771e4f11efc0cd8e8183b5998c6f30
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4961074
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Commit-Queue: Scott Haseley <shaseley@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1213569}
This CL goes throughout the Chromium codebase and puts the deletion code
where necessary so that when kCdmStorageDatabase flag is enabled, the
BrowsingDataRemoverBrowser tests pass. This CL also tests that when
incognito, the CdmStorage.db is not written to disk.
Testing: I enabled kCdmStorageDatabase and ran browser_tests. Without
these changes, the
IncognitoBrowsingDataBrowserTest.StorageDoesntWriteToDisk and
BrowsingDataRemoverBrowserTest.StorageRemovedFromDisk would fail. These
changes now allow these tests to pass when the flag is enabled.
Bug: 1454512
Change-Id: Iadcc69781f7abd3a545f678519c28d6a51000d3a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4936193
Reviewed-by: John Rummell <jrummell@chromium.org>
Commit-Queue: Vikram Pasupathy <vpasupathy@chromium.org>
Reviewed-by: Bo Liu <boliu@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1210620}
StoragePartitionImpl::OnBrowserContextWillBeDestroyed is called by
BrowserContextImpl prior to destruction, which allows the partition to
shut down objects that hold raw pointers to about-to-be-destroyed
objects. This fixes dangling pointers in content_index and
FileSystemAccessManager** that result from objects being destroyed in
~ProfileImpl before shutting down all partitions.
**This CL also changes a couple browser tests to clear the testing
permission context to fix the remaining FileSystemAccessManager
dangling pointer causes.
Bug: 1471071, 1471072, 1471074
Change-Id: I569a2051f9e69e53f2d88d3ce4b6caeb4f74549f
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4869214
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Reviewed-by: Sergey Poromov <poromov@chromium.org>
Commit-Queue: Scott Haseley <shaseley@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1209101}
DevToolsBackgroundServicesContextImpl can outlive its BrowserContext in
tests, which causes a dangling pointer. This CL fixes this by:
- Fixing destruction order in ServiceWorkerUpdateJobTest, which was
straightforward.
Note: this also fixes an unrelated dangling pointer in one of the
ServiceWorkerUpdateJobTest tests, which was straightforward and
part of the same destruction sequence.
- Making DevToolsBackgroundServicesContextImpl uniquely owned (no
longer ref counted). The main interesting bits here were:
- Get the DevToolsBackgroundServicesContextImpl directly rather
than passing it across tasks (for service worker callbacks).
This avoids a dangling pointer in the callback.
- Plumb the Shutdown signal through BackgroundFetchContext to
other objects that hold a raw_ptr to the devtools service. This
can be further improved by making BackgroundFetchContext uniquely
owned.
Bug: 1471073
Change-Id: I457c8492d21299dd60368711ed3814f3cf8fc3ec
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4868640
Commit-Queue: Scott Haseley <shaseley@chromium.org>
Reviewed-by: Rouslan Solomakhin <rouslan@chromium.org>
Reviewed-by: Andrey Kosyakov <caseq@chromium.org>
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1199589}
There are two headers to declare features in content.
- the public one: `content/public/common/content_features.h`
- the private one: `content/common/features.h`.
Unfortunately, most are declared in the public one, despite being used
privately exclusively. This violate the `content/public/` rules. This
patches provides a fix.
Parts of this patch was made programmatically using this script:
https://paste.googleplex.com/6699322946093056, with the following
output: https://paste.googleplex.com/5591288895242240
This patch:
1. Update `docs/how_to_add_your_feature_flag.md` to incentive
developers to the non public versions.
2. Move ~70 features back into the private version.
3. Programmatically update the includes to include the correct
#include header(s).
4. For consistency and minimizing the amount of files modified,
the two headers to use the `features::` namespace.
AX-Relnotes: n/a.
Change-Id: Id9126a95dfbc533d4778b188b659b5acc9b3d9e3
Bug: None
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4836057
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Commit-Queue: Arthur Sonzogni <arthursonzogni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1194718}
This feature will be needed in the //components/attribution_reporting
directory for future refactoring; moving it there prevents a dependency
cycle between it and blink. It is also more logically located there
anyway since it controls behavior in both blink and the browser.
Bug: 1479944
Change-Id: Iee7d71dc93888215a887ac0e49d8edc1c9c6c274
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4849148
Reviewed-by: Avi Drissman <avi@chromium.org>
Reviewed-by: John Delaney <johnidel@chromium.org>
Commit-Queue: Andrew Paseltiner <apaseltiner@chromium.org>
Reviewed-by: Nico Weber <thakis@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1193685}
### Background:
- keepalive requests are a subset of Fetch requests.
- FetchLater request is a new type of Fetch request. Its keepalive
flag is always true. When presents, `kFetchLaterAPI` must be true.
The [previous CL][1] replaces all occurrences of the feature flag
`kKeepAliveInBrowserMigration` with a function that checks additional
feature flag `kFetchLaterAPI`. However, it incorrectly enables the
migration path for non-fetchLater keepalive requests.
The correct paths looks like:
1. For a fetchLater keepalive request (generated from entirely new
API), `kFetchLaterAPI` must be true. It should go through the code
path after keepalive migration. content::KeepAliveURLLoaderService
should handle the request.
2. For a non-fetchLater keepalive request:
- if `kKeepAliveInBrowserMigration` is false, it should go through
the existing & before migration path. Some checks lie in
RenderProcessHost should apply to it.
- if `kKeepAliveInBrowserMigration` is true, it should go through
the after migration path. content::KeepAliveURLLoaderService
should handle the request.
To summarize, content::KeepAliveURLLoaderService must be up if one of
the two features is enabled. But it should not handle the feature that
is not enabled.
This CL renames the `IsKeepAliveInBrowserMigrationEnabled()` function
to `IsKeepAliveURLLoaderServiceEnabled()`, which should only be used
in setting up KeepALiveURLLoaderService-related code path in content.
TODOs added by this CL is addressed in [another CL][2]. e2e tests are also added by that CL chain.
[1]: https://crrev.com/c/4752743
[2]: https://crrev.com/c/4803083/22..24
Bug: 1465781,1356128
Change-Id: I9a7c927ab1a248abf3415e126ea190b0b56833b4
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4847647
Commit-Queue: Ming-Ying Chung <mych@chromium.org>
Reviewed-by: Nate Chapin <japhet@chromium.org>
Reviewed-by: Rakina Zata Amni <rakina@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1193462}
When StoragePartition::OnClearSiteData() is called, the call
takes the follow route:
> StoragePartition::OnClearSiteData()
> ClearSiteDataHandler::HandleHeader()
> ClearSiteData()
> BrowsingDataRemoverImpl::RemoveWithFilterAndReply()
> StoragePartition::ClearData()
However, any StoragePartition calls OnClearSiteData() will eventually
result in default StoragePartition calling ClearData().
This chain of changes attempts to fix this by passing the
StoragePartition along to have the final ClearData() call called on the
correct StoragePartition.
We are also updating the definition of DATA_TYPE_ON_STORAGE_PARTITION
because only subsets of DATA_TYPE_ON_STORAGE_PARTITION are allowed by
BrowsingDataRemover to be the mask when a StoragePartition is specified
in the filter.
Bug: 1449362
Change-Id: I766d02a89ee636321625e30b80b1f38f15885e74
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4770335
Reviewed-by: Robbie McElrath <rmcelrath@chromium.org>
Reviewed-by: Joshua Bell <jsbell@chromium.org>
Commit-Queue: Zelin Liu <zelin@chromium.org>
Reviewed-by: Martin Šrámek <msramek@chromium.org>
Reviewed-by: Nasko Oskov <nasko@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1188471}
By disabling this policy, administrators can disable the Compression
Dictionary Transport feature. This is useful when they are using
firewalls which are decrypting TLS traffic using a private interception
certificate, because this feature may have interoperability issues with
such firewalls.
Bug: 1471795, 1413922
Change-Id: I582212a23046e905165c74f8123e94a2bb66d086
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4768717
Commit-Queue: Tsuyoshi Horo <horo@chromium.org>
Reviewed-by: Owen Min <zmin@chromium.org>
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Reviewed-by: Patrick Meenan <pmeenan@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1183864}
