The SharedStorageWorkletHostManager class has expanded beyond just
managing worklet hosts to include lock management. Rename it to better
reflect its broader responsibilities.
The name "SharedStorageRuntimeManager" is chosen because:
1. It avoids confusion with SharedStorageManager (which manages the
persistent database).
2. "Runtime" emphasizes that it manages ephemeral/in-memory components
like the worklet hosts and the locks.
Bug: 373899210
Change-Id: I8e64ae6df876c0f43a6096e4b8b2ab43a4cac3c6
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6003136
Reviewed-by: Cammie Smith Barnes <cammie@chromium.org>
Auto-Submit: Yao Xiao <yaoxia@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Commit-Queue: Avi Drissman <avi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1381418}
The is_request_for_primary_main_frame parameter of CreateLoginDelegate()
could mean whether the request is for any resources in the primary main
frame, or whether the request is for primary main frame navigation.
The current name has confused people and caused bugs. The bugs were
fixed in http://crrev.com/c/5882129. As a follow up of that change, this
change adds _navigation to the parameter name to make it clear so that
we don't have this confusion in the future.
Bug: 40792637
Change-Id: I6cb8f729b703ad2ca23488287436424a10a3ace8
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5910076
Reviewed-by: Nasko Oskov <nasko@chromium.org>
Reviewed-by: Peter Beverloo <peter@chromium.org>
Reviewed-by: Emily Stark <estark@chromium.org>
Commit-Queue: Liang Zhao <lzhao@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#1367732}
As we move on to using just the CdmStorageDatabase, remove the flags for
cleanup.
testing: tests pass, I also verified storage functionality works by
playing with persistent state required in Integration Console.
OBSOLETE_HISTOGRAMS=No longer doing the migration.
Bug: 40272342
Change-Id: I1029ff67b35639040a9abbc564725eac4d069149
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5905186
Reviewed-by: Evan Liu <evliu@google.com>
Reviewed-by: John Rummell <jrummell@chromium.org>
Commit-Queue: Vikram Pasupathy <vpasupathy@chromium.org>
Reviewed-by: Ayu Ishii <ayui@chromium.org>
Reviewed-by: Dave Tapuska <dtapuska@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1364241}
There is a is_main_frame parameter used by basic authentication handling
code to interact with WebRequestAPI and login dialog showing code, and
that parameter is not set correctly for certain scenarios.
For WebRequestAPI, the parameter is used to adjust child_id to -1 of
proxied_request_id in WebRequestAPI::MaybeProxyAuthRequest for correctly
identifying the request. However, WebRequestAPI code uses -1 as
render_process_id not by whether it is main frame, but by whether it is
navigation. Therefore, with current code, we will not receive
onAuthRequired for sub frame navigations.
For login dialog showing code, it behaves differently by whether it is
main frame navigation or other requests. However, basic authentication
handling code in StoragePartitionImpl::OnAuthRequired treat this
parameter as meaning requests for main frame navigation or subresource
requests in main frame when the frame is under service worker.
Therefore, with current code, we will not show login dialog for
subresources when the page is under service worker control.
To fix the issues, we add another parameter to indicate whether it is a
request for navigation and use that when interacting with WebRequestAPI,
and correctly set is_main_frame as false for subresource requests when
the page is under service worker control.
Added WebRequestAPI tests for sub frame navigation and sub resource
request, for the cases where the page is under service worker control
and where it is not under service worker control.
Also updated ServiceWorkerBasicAuthTest to reflect the correct
expectation for subresource requests, and expand the tests to cover both
the case where the page is under service worker control and not under
service worker control.
Bug: 40676156,40792637,41459173
Change-Id: I6a716ec0228fcb2332a985c15c9bffbabb4a4dde
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5882129
Reviewed-by: Emily Stark <estark@chromium.org>
Commit-Queue: Liang Zhao <lzhao@microsoft.com>
Reviewed-by: David Bertoni <dbertoni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1363749}
This allows lock requests to be identified by types beyond just storage
bucket IDs. This generalization supports use cases like the shared
storage web locks proposal ([1]), which requires its own lock scope
(i.e. per-origin) without integrating with storage buckets or the quota
database. The term "bucket" has been replaced with the more generic
"lock_group" throughout the code.
[1] https://github.com/WICG/shared-storage/pull/199
Bug: 368816425
Change-Id: Iaabd48c4fc5e64d302b2efdadba5cac6f99ebe3c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5879028
Reviewed-by: Ayu Ishii <ayui@chromium.org>
Commit-Queue: Yao Xiao <yaoxia@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1362083}
Add indexed_db namespace and remove IndexedDB prefix from many classes.
The indexed_db namespace already existed but was used sparingly. Use it
more thoroughly in //content/browser/indexed_db and
//components/services/storage/indexed_db
Bug: none
Change-Id: Id4bb701a86bd25645737bd045b71d4964adef422
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5854146
Reviewed-by: Mike Wasserman <msw@chromium.org>
Reviewed-by: Tom Sepez <tsepez@chromium.org>
Reviewed-by: John Lee <johntlee@chromium.org>
Commit-Queue: Evan Stade <estade@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1355379}
This limitation is set to roughly the largest number of threads that a
legitimate site could want to use.
This defines a "site" as a storage key's `top_level_site()` rather than
a storage key, in case a single site tries to get around this cap by
embedding a lot of iframes. But mostly this limitation is designed to
keep honest sites honest and not to defend against bad actors, as there
are many other ways to use up a lot of system resources and a DOS is
not normally considered a security bug.
Bug: 40279485
Change-Id: Ibbdc9a64c980910e84317631feea3ebd93b95221
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5827820
Reviewed-by: Ayu Ishii <ayui@chromium.org>
Commit-Queue: Evan Stade <estade@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1353425}
PlatformNotificationContext, and the PlatformNotificationServiceProxy
that it owns, hold pointers to the BrowserContext and
PlatformNotificationService that need to be cleaned up before those
objects are destroyed.
Fixed: 40278076
Change-Id: Icb47cc325fa433e4415bc0cd0b45bc84dfc00f9d
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5824940
Reviewed-by: Peter Beverloo <peter@chromium.org>
Reviewed-by: Arthur Sonzogni <arthursonzogni@chromium.org>
Commit-Queue: Mark Rowe <markrowe@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1350442}
When a fenced frame has its network access revoked, the associated
partition and credentialless iframe nonces are sent to the
network service. There, the nonces are stored and used to prevent
requests from being sent. When a fenced frame is destroyed, those
nonces will now be removed from the network service and the
associated data structure in StoragePartitionImpl.
The removal occurs after a one-minute delay in order to prevent a
race, where a fenced frame could sent requests while it is being
torn down because the nonce was cleaned up immediately.
This CL contains a fairly simple unit test in the network context,
but the browsertest is unfortunately much more involved; I had to
add some kinda gross test-only code to shorten the delay and
notify that cleanup was finished, as well code to manually send
network requests with the fenced frame nonce after the frame
is destroyed.
Change-Id: I15718fa0daa540c25f268418fa217bad8770b8be
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5787550
Reviewed-by: Nasko Oskov <nasko@chromium.org>
Commit-Queue: Andrew Verge <averge@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1344298}
Currently, `IndexedDBClientStateCheckerFactory::InitializePendingRemote`
generates an `UnguessableToken` tied to the "associated RFH" of the
`BucketContext` if it exists, else a random one per call.
Conceptually, this token represents the "client" of an IndexedDB factory
which can be a render frame, a dedicated worker, a shared worker, or a
service worker. However, we need dedicated workers and their parent
render frames to be represented by the same token since the main use of
this token is to prevent a page (along with its dedicated workers) from
blocking itself from the BFCache - see https://crbug.com/343519262.
But this requirement is buried in the nuances of the implementations of
`BucketContext::GetAssociatedRenderFrameHostId()` and
`InitializePendingRemote()`, which led to the above bug. In addition,
because this token is not derived from one of the existing Blink tokens
that represent the above potential clients of IndexedDB, we had to add
an explicit method to get the DevTools token for the client from the
`IndexedDBClientStateChecker` to implement additional functionality in
https://chromium-review.googlesource.com/c/chromium/src/+/5607565.
This CL addresses both these problems by formalizing the concept of an
IndexedDB client in terms of existing tokens defined by Blink. This
"`BucketClientInfo`" is plumbed through to those IndexedDB classes that
already know the concept of a storage "Bucket" through existing classes
such as `BucketInfo` and `BucketId`.
Because the tokens used in `BucketClientInfo` are now derived from
existing Blink tokens, we don't need an explicit `GetDevToolsToken()`
method anymore and `IndexedDBInternalsUI` can get a handle to the
`DevToolsAgentHost` directly from `BucketClientInfo`.
Also, since `BucketClientInfo` is passed down to the indexeddb-internals
page, we can expose additional information about the clients (such as
the type - tab or specific worker), URL, etc. in future CLs.
Bug: 349019967, 336960312
Change-Id: I173dc836a1616b574368e8c65c98fc70b1a5ec09
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5708948
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Commit-Queue: Daniel Cheng <dcheng@chromium.org>
Auto-Submit: Abhishek Shanthkumar <abhishek.shanthkumar@microsoft.com>
Reviewed-by: Dave Tapuska <dtapuska@chromium.org>
Reviewed-by: Brad Triebwasser <btriebw@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1344284}
This CL introduces `ReconnectableURLLoaderFactoryForIOThreadWrapper`,
to merge `StoragePartitionImpl::url_loader_factory_getter_`
and `shared_url_loader_factory_for_browser_process_`.
This is preparation for [1] that creates two sets of
`ReconnectableURLLoaderFactory*`s for internal/WebPlatform requests,
and merging two `ReconnectableURLLoaderFactory*` members into one
in `StoragePartitionImpl` makes [1] easier.
[1] https://chromium-review.googlesource.com/c/chromium/src/+/5649232
This CL also adds comments and thread checks.
Bug: 41497033, 346686150
Change-Id: Ie2fdd3ab9303eb1017b9f9d475201c2036b10936
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5627156
Commit-Queue: Hiroshige Hayashizaki <hiroshige@chromium.org>
Reviewed-by: Kouhei Ueno <kouhei@chromium.org>
Reviewed-by: Arthur Sonzogni <arthursonzogni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1332262}
This CL moves the definition of GlobalRequestID::MakeBrowserInitiated()
out of the header file to prevent inlining. The method relies on a
static local atomic to guarantee that it vends unique IDs. Although a
statically-linked binary would only have a single definition for
MakeBrowserInitiated(), component builds could be problematic. If there
were multiple copies of MakeBrowserInitiated(), it would not be
guaranteed to vend unique IDs.
Separately, this CL also sidesteps some implementation-defined narrowing
integer conversions related to the `child_id` and `request_id` fields.
Bug: 352690892, 40065303
Change-Id: I49ac933a663bbce225b1098f38c8d4e5dfe3d237
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5702737
Reviewed-by: Joe Downing <joedow@chromium.org>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Adam Rice <ricea@chromium.org>
Commit-Queue: Dan McArdle <dmcardle@chromium.org>
Reviewed-by: Dave Tapuska <dtapuska@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1328175}
To unify how the underlying URLLoaderFactory is created
in two similar paths:
- ReconnectableURLLoaderFactory /
StoragePartitionImpl::GetURLLoaderFactoryForBrowserProcess()
- URLLoaderFactoryGetter /
StoragePartitionImpl::GetURLLoaderFactoryForBrowserProcessIOThread()
This CL makes URLLoaderFactoryGetter to call
StoragePartitionImpl::CreateURLLoaderFactoryForBrowserProcessInternal
via `CreateCallback`, just like the
GetURLLoaderFactoryForBrowserProcess path does.
The diff from the previous
`URLLoaderFactoryGetter::HandleNetworkFactoryRequestOnUIThread()`
is to add the URLLoaderInterceptor on the UI thread.
Therefore this CL removes the URLLoaderFactoryGetter interceptor:
Instead of intercepting
`URLLoaderFactoryGetter::GetURLLoaderFactory()` on IO thread,
the general UI thread interceptor intercepts the requests on
UI thread.
Bug: 346686150
Change-Id: I3018c1b95a4490758bd1886c61888de200c36e30
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5624793
Reviewed-by: Kouhei Ueno <kouhei@chromium.org>
Reviewed-by: Arthur Sonzogni <arthursonzogni@chromium.org>
Commit-Queue: Arthur Sonzogni <arthursonzogni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1326765}
This CL decouples
`StoragePartitionImpl::URLLoaderFactoryForBrowserProcess`
from `StoragePartitionImpl` and introduces it as a general
URLLoaderFactory with reconnection support.
Instead of calling Shutdown() explicitly,
`ReconnectableURLLoaderFactory` relies on `WeakPtr` invalidation.
ReconnectableURLLoaderFactory is placed in
content/browser/url_loader_factory_getter.h/cc
because ReconnectableURLLoaderFactory and
URLLoaderFactoryGetter will be merged in
https://chromium-review.googlesource.com/c/chromium/src/+/5627156.
This CL shouldn't change the behavior.
Bug: 346686150
Change-Id: I0528ea2c6bd1364ae375f297de6ba7ee57e7a362
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5624790
Reviewed-by: Arthur Sonzogni <arthursonzogni@chromium.org>
Commit-Queue: Hiroshige Hayashizaki <hiroshige@chromium.org>
Reviewed-by: Kouhei Ueno <kouhei@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1324727}
Certain requests may request, but not require, a client cert. Today,
this will result in one of three things happening if there isn't a
client cert available (either from a previous request or from
enterprise policy):
1) The request will fail
2) The user will be shown a cert picker dialog
3) The request will continue without a certificate
On desktop platforms for WebContents-based requesting contexts:
* If there are no certs to choose from, the request will continue
without a cert.
* If there are client certs and the WebContents supports showing
dialogs, the cert picker will be shown.
* If there are certs and the WebContents does not support showing
dialogs, the request will fail.
On Android for WebContents-based requesting contexts:
* We will always call out to the native cert-picker, which may or
may not show a dialog (depending on other device configurations
which Chrome doesn't know about).
On desktop and Android platforms for service worker requesting
contexts:
* The request will always fail.
This CL changes this behavior to allow requests from extension
background service workers to proceed without a client cert if there
are no certs to choose from; this then matches the behavior for
extension background and offscreen WebContents (which do not support
showing dialogs).
Bug: 333954429
Change-Id: Ia6111f3bd499998d6244945daa13ac67774804bf
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5455480
Reviewed-by: Emily Stark <estark@chromium.org>
Reviewed-by: David Benjamin <davidben@chromium.org>
Reviewed-by: Richard (Torne) Coles <torne@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Reviewed-by: Luke Halliwell <halliwell@chromium.org>
Reviewed-by: Andrey Kosyakov <caseq@chromium.org>
Commit-Queue: Devlin Cronin <rdevlin.cronin@chromium.org>
Reviewed-by: Wez <wez@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1322530}
Since multiline/multipath is currently unsupported; for enums that
require multiple file changes (e.g. histograms.xml and enums.xml) I've
used the following chain:
C++ declaration > enums.xml > histograms.xml > C++ declaration
NO_IFTTT=Adding linter not changing it.
Bug: 348206841
Change-Id: I97f4741f40592c7bd4be32e5de17236acc2bb34c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5645378
Reviewed-by: Evan Stade <estade@chromium.org>
Reviewed-by: Christian Dullweber <dullweber@chromium.org>
Auto-Submit: Mariam Ali <alimariam@google.com>
Commit-Queue: Mariam Ali <alimariam@google.com>
Cr-Commit-Position: refs/heads/main@{#1320198}
To allow updating the key of `service_worker_clients_by_uuid_`
correctly from `ServiceWorkerClient::UpdateUrls()`
even after `ServiceWorkerContextWrapper::DidDeleteAndStartOver()`,
this CL splits the client-ownership-related members from
`ServiceWorkerContextCore` into a new class
`ServiceWorkerClientOwner`.
`ServiceWorkerClient::owner_` keeps access to
`ServiceWorkerClientOwner` while `ServiceWorkerClient::context_` is
still cleared on `DidDeleteAndStartOver`.
A regression test will be added in
https://chromium-review.googlesource.com/c/chromium/src/+/5590788.
The DCHECK() in OnContainerHostReceiverDisconnected()
(that would fail with the regression test without this CL)
is turned to CHECK() to confirm the correctness.
Bug: 336154571, 344130634
Change-Id: If772d4f38749ed0ead3937084287e1c1c26259ee
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5587598
Reviewed-by: Hiroki Nakagawa <nhiroki@chromium.org>
Commit-Queue: Hiroshige Hayashizaki <hiroshige@chromium.org>
Reviewed-by: Yoshisato Yanagisawa <yyanagisawa@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1313606}
Currently, session cookies can be retained indefinitely as long as
session restore is on (which is true by default).
This may not be desirable or expected, and is not behavior replicated
by WebKit or Firefox.
This CL implements one potential approach to clearing stale session
cookies. It defines stale as not read or written within 7 days and
clears session cookies after the session restore has completed.
This is off by default and will not be turned on by default for some
time.
Bug: 40285083
Change-Id: I30a209e4b20f5283ab015c311887c943a3e3976e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5580590
Reviewed-by: Avi Drissman <avi@chromium.org>
Reviewed-by: Nasko Oskov <nasko@chromium.org>
Reviewed-by: Maks Orlovich <morlovich@chromium.org>
Reviewed-by: Steven Bingler <bingler@chromium.org>
Auto-Submit: Ari Chivukula <arichiv@chromium.org>
Commit-Queue: Ari Chivukula <arichiv@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1308720}
...since that's easy to break by accident, and would slow down loading
of pages right after startup by making them block until all cookies are
loaded.
This is expressed a a time metric since it actually happens for the
special safe browsing cookiejar, but it doesn't matter there since
that has ~1 cookie.
... And remove kPreloadCookies experiment which did that for field
trial config, but thankfully not for real world, while trying to
accomplish the exact opposite.
Bug: 40225126
Change-Id: I602572844a17e5e56ed2a11868598cdd6db51712
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5581882
Reviewed-by: Steven Bingler <bingler@chromium.org>
Reviewed-by: Camille Lamy <clamy@chromium.org>
Commit-Queue: Maks Orlovich <morlovich@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1308631}
`IndexedDBConnection` maintains a token identifying the client that
initiated the connection to support certain BFCache scenarios.
See https://chromium-review.googlesource.com/c/chromium/src/+/5203165.
This token is currently generated by
`IndexedDBClientStateCheckerFactory` based on the RFH ID of the client.
However, `IndexedDBBucketContext` - which implements the `IDBFactory`
interface and creates the IDB connections - can uniquely identify the
client by the `ReceiverId` of the mojo call creating the connection.
Hence, this CL passes the `ReceiverId` returned by `current_receiver()`
as the `client_token_` to `IndexedDBConnection`.
This CL has no functional changes and will help with further planned
work in this space, as discussed in the linked bug.
Bug: 336960312
Change-Id: Ibd10331f8034db5b076f8c9525dde027e55cb505
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5529157
Reviewed-by: Nasko Oskov <nasko@chromium.org>
Commit-Queue: Brad Triebwasser <btriebw@chromium.org>
Reviewed-by: Evan Stade <estade@chromium.org>
Reviewed-by: Brad Triebwasser <btriebw@chromium.org>
Auto-Submit: Abhishek Shanthkumar <abhishek.shanthkumar@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#1299392}
The canonical bug format is TODO(crbug.com/<id>). TODOs of the
following forms will all be migrated to the new format:
- TODO(crbug.com/<old id>)
- TODO(https://crbug.com/<old id>)
- TODO(crbug/<old id>)
- TODO(crbug/monorail/<old id>)
- TODO(<old id>)
- TODO(issues.chromium.org/<old id>)
- TODO(https://issues.chromium.org/<old id>)
- TODO(https://issues.chromium.org/u/1/issues/<old id>)
- TODO(bugs.chromium.org/<old id>)
Bug id mapping is sourced from go/chrome-on-buganizer-prod-issues.
See go/crbug-todo-migration for details.
#crbug-todo-migration
Bug: b/321899722
Change-Id: Ibc66b8c440e4bcdef414e77fef4d9874d2ea9951
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5493800
Auto-Submit: Alison Gale <agale@chromium.org>
Commit-Queue: Alison Gale <agale@chromium.org>
Reviewed-by: Peter Boström <pbos@chromium.org>
Owners-Override: Alison Gale <agale@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1293330}
Move the map of PolicyContainerHosts keyed by LocalFrameToken from
PolicyContainerHost to StoragePartition. This changes how
PolicyContainerHosts are accessed. Previously there was a global map of
LocalFrameTokens to PolicyContainerHosts. Now there is a map on
StoragePartition of LocalFrameTokens to NavigationStateKeepAlives, from
which the PolicyContainerHost can be accessed. If there is not a
NavigationStateKeepAlive, the PolicyContainerHost should be accessed
directly from the RenderFrameHost.
This also introduces a source SiteInstance to NavigationStateKeepAlive
to be kept alive. This also implicitly keeps the associated
SiteInstanceGroup alive.
Navigations initiated from a different StoragePartition do not inherit
origins or policies across StoragePartitions, so the PolicyContainerHost
and source SiteInstance will not be leaked across StoragePartition
boundaries (e.g. in <webview> tags).
some NavigationPolicyContainerBuilder unit tests to browser tests
PERFETTO_TESTS=`autoninja -C out/Default perfetto_diff_tests && out/Default/bin/run_perfetto_diff_tests`
Test: Enable NavigationBrowserTest that was added previously, move
Bug: 323753235
Change-Id: I8924a8f75831e3b3da2922024349632fe057bfe6
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5311170
Reviewed-by: Robert Kaplow <rkaplow@chromium.org>
Reviewed-by: Charlie Reis <creis@chromium.org>
Reviewed-by: Alexander Timin <altimin@chromium.org>
Commit-Queue: Sharon Yang <yangsharon@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1291412}
Service crashes.
NetworkContext has a member `network_revocation_nonces_`, which is a
set of nonces whose network access is revoked. When NetworkService
crashes, it will destroy its NetworkContext.
When NetworkContext is recreated, `network_revocation_nonces_` must be
restored to the state before the crash. This is done using the copy of
nonces saved in StoragePartition. Otherwise, fenced frames that
previously have network disabled and got access to cross-site data,
will regain network access.
Bug: 41488151
Change-Id: If84d1b592b6c2500fa90439c5db7fe1ec6f60ca7
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5440136
Reviewed-by: mmenke <mmenke@chromium.org>
Reviewed-by: Garrett Tanzer <gtanzer@chromium.org>
Reviewed-by: Dominic Farolino <dom@chromium.org>
Commit-Queue: Xiaochen Zhou <xiaochenzh@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1291270}
The canonical bug format is TODO(crbug.com/<id>). TODOs of the
following forms will all be migrated to the new format:
- TODO(crbug.com/<old id>)
- TODO(https://crbug.com/<old id>)
- TODO(crbug/<old id>)
- TODO(crbug/monorail/<old id>)
- TODO(<old id>)
- TODO(issues.chromium.org/<old id>)
- TODO(https://issues.chromium.org/<old id>)
- TODO(https://issues.chromium.org/u/1/issues/<old id>)
- TODO(bugs.chromium.org/<old id>)
Bug id mapping is sourced from go/chrome-on-buganizer-prod-issues.
See go/crbug-todo-migration for details.
#crbug-todo-migration
Bug: b/321899722
Change-Id: Iebe070b9ed793ecdfc43c3a3570f1808b7ddd221
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5470014
Reviewed-by: Darryl James <dljames@chromium.org>
Owners-Override: Alison Gale <agale@chromium.org>
Commit-Queue: Alison Gale <agale@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1290677}
The canonical bug format is TODO(crbug.com/<id>). TODOs of the
following forms will all be migrated to the new format:
- TODO(crbug.com/<old id>)
- TODO(https://crbug.com/<old id>)
- TODO(crbug/<old id>)
- TODO(crbug/monorail/<old id>)
- TODO(<old id>)
- TODO(issues.chromium.org/<old id>)
- TODO(https://issues.chromium.org/<old id>)
- TODO(https://issues.chromium.org/u/1/issues/<old id>)
- TODO(bugs.chromium.org/<old id>)
Bug id mapping is sourced from go/chrome-on-buganizer-prod-issues.
See go/crbug-todo-migration for details.
#crbug-todo-migration
Bug: b/321899722
Change-Id: Ieeb461e2d489e86fd50b87a2a0721a2be34520c3
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5467317
Owners-Override: Alison Gale <agale@chromium.org>
Commit-Queue: Darryl James <dljames@chromium.org>
Commit-Queue: Alison Gale <agale@chromium.org>
Reviewed-by: Darryl James <dljames@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1290198}
ConcurrentClosures doesn't require to know the callback count ahead
of time and therefore reduces the risk of errors or unnecessary
Run() calls for branches that don't actually have a task to run.
This CL replaces a couple of tricky barriers with concurrent closures.
Change-Id: Idad3e9e03882c66560ceb340ba0cc65b0ec39fff
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5453661
Commit-Queue: Christian Dullweber <dullweber@chromium.org>
Auto-Submit: Christian Dullweber <dullweber@chromium.org>
Reviewed-by: Ayu Ishii <ayui@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1289819}
This CL moves the business logic from the already long function
ClearDataOnUIThread to the CdmStorageManager so the splitting is done
closer down and the long function doesn't become longer.
Bug: 40272342
Change-Id: Ib680cee549c4f27b4243b8f174762e0bc9f9c188
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5377658
Commit-Queue: Vikram Pasupathy <vpasupathy@chromium.org>
Reviewed-by: Evan Stade <estade@chromium.org>
Reviewed-by: John Rummell <jrummell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1281350}
On Profile destruction, currently there is a race with
the DatabaseTracker shutdown. DatabaseTracker shutdown
will post task[1] on the database task runner because
it needs to do file I/O. However it also has some logic
to retrieve info for special storage policies from the
Profile which may already be destroyed by that time.
This change removes logic for special storage policy from
DatabaseTracker. DatabaseTracker(WebSQL) is removed
from all platforms as of M119 except for WebView, which does
not utilize the special storage policy. All policy and
deprecation support have ended with M123. Therefore cleaning
up the code to avoid the race.
[1]https://source.chromium.org/chromium/chromium/src/+/main:content/browser/storage_partition_impl.cc;l=1200;drc=be92f4cc2f137460213d52a926c9477275a456c5
Bug: 323898565, 325476286
Change-Id: Ie2ef898c558308439a8b0d3fdf67f7157440b20a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5288855
Commit-Queue: Ayu Ishii <ayui@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Reviewed-by: Evan Stade <estade@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1276451}
Some clear browsing history / data functionality use filters rather
than specifying storage_keys to delete. This CL now adds the delete
by filter functionality to the CdmStorageDatabase data, along with
enabling the browsing_data_remover browsertests for Filter, and unit
tests to test the deletion by filter functionality.
chrome: Populate CdmStorageDatabase data in Site Data Counter
Bug: 1454512, 40926576
Change-Id: I8223aafbd28544309f01d92891f8fbceb8a439db
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5365810
Reviewed-by: Evan Liu <evliu@google.com>
Reviewed-by: John Rummell <jrummell@chromium.org>
Commit-Queue: Vikram Pasupathy <vpasupathy@chromium.org>
Reviewed-by: Evan Stade <estade@chromium.org>
Reviewed-by: Christian Dullweber <dullweber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1275284}
CdmStorageDatabase data is now counted via the site_data_counting_helper
so now we can enable browsing_data_remover_browsertest to test out the
deletion and counting usage functions of the CdmStorageDatabase.
There is a TODO to implement deletion via filter, and to enable the test
once the deletion via filter is implemented. A stub method is added for
now, the CL to implement that will come soon.
Bug: 1454512
Change-Id: I9970b82260cfe095c78f4a86f9623a98c3e70719
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5366261
Reviewed-by: John Rummell <jrummell@chromium.org>
Commit-Queue: Vikram Pasupathy <vpasupathy@chromium.org>
Reviewed-by: Christian Dullweber <dullweber@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1275282}
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}
