This change removes usages of StorageType in QuotaClient methods.
After StorageType::kSyncable deprecation, all other storage types
except kTemporary are deprecated. So we no longer need to specify
StorageType. Data that was previously associated with kSyncable
is now part of kTemporary.
Main part of this change is in quota_client.mojom and updates
all overrides and callers of impacted methods.
Bug: 40211051
Change-Id: I000a457346dd1e383c6252dfa22c75cfd3c6e721
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6368800
Reviewed-by: Ken Buchanan <kenrb@chromium.org>
Commit-Queue: Ayu Ishii <ayui@chromium.org>
Reviewed-by: Tsuyoshi Horo <horo@chromium.org>
Reviewed-by: Hiroki Nakagawa <nhiroki@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1435031}
After a lot of investigation, it's still not clear how to trigger this,
because it seems to require storing a File in IndexedDB that has unknown
size and/or modification date. I have not been able to construct such a
file without running into other errors that would prevent storing and
reading the file.
Bug: 393395443
Change-Id: I9b5eb531bb7c9e1338fdd70a6a16e578ef43d668
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6368285
Reviewed-by: Steve Becker <stevebe@microsoft.com>
Commit-Queue: Evan Stade <evanstade@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#1434606}
This change removes usages of StorageType in QuotaManager methods.
After StorageType::kSyncable deprecation, all other storage types
except kTemporary are deprecated. So we no longer need to specify
StorageType. Data that was previously associated with kSyncable
is now part of kTemporary.
Main part of this change is in
storage/browser/quota/quota_manager_impl.cc. All other files
are either updating calls to QuotaManager or updates the
overridden functionality.
Further cleanup to remove usage in QuotaDatabase and QuotaClients
will be done in a follow-up.
Bug: 40211051
Change-Id: Id7232aa518bba8097559200fde2f330488dd2fa1
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6350696
Commit-Queue: Ayu Ishii <ayui@chromium.org>
Reviewed-by: Christian Dullweber <dullweber@chromium.org>
Reviewed-by: Tsuyoshi Horo <horo@chromium.org>
Reviewed-by: Bo Liu <boliu@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1434297}
Iterative process to reduce the initial set of warnings. Use
UNSAFE_TODO() unless include rules preclude compiler_spcific.h,
in which case use the file-wide pragma.
Bug: 390223051
Change-Id: I0b4d6020dd30a5184ebd8178996d047205476d39
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6362954
Reviewed-by: Alex Gough <ajgo@chromium.org>
Owners-Override: Alex Gough <ajgo@chromium.org>
Commit-Queue: Tom Sepez <tsepez@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1433839}
... for a specific error condition.
The bug is a result of indexes requiring keeping in-memory metadata
in sync with database state. When in-memory metadata is updated
(in this case, deleted), and then a subsequent database operation
fails, existing code restores the change to in-memory metadata (in this
case, re-adding it). But there was one error condition where the
metadata wasn't updated again. This addresses that branch.
This is a prospective fix for the linked bug, which has eluded
reproduction. A DWOC is also added which is intended to make the crash
non-fatal, but noisy, and if it never triggers we'll have some
indication that this prospective fix was effective.
(See also discussion on bug, in particular re: lack of new test
coverage.)
Bug: 398879932
Change-Id: I2a0954ea3979d9c70e7de23120fb0cfbbe8b36fa
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6354201
Commit-Queue: Abhishek Shanthkumar <abhishek.shanthkumar@microsoft.com>
Reviewed-by: Steve Becker <stevebe@microsoft.com>
Auto-Submit: Evan Stade <evanstade@microsoft.com>
Reviewed-by: Abhishek Shanthkumar <abhishek.shanthkumar@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#1433404}
This change addresses the flakiness in the tests caused by improper
initialization of BucketLocator.
Key Points:
The expected count for various assertions of notify_list_changed_count
has been decreased. This adjustment is necessary because there are two
definitions in indexed_db_context_impl.cc that call
OnIndexedDBListChanged internally (OnFilesWritten and
DidForceCloseForDeleteBucketData).
When OnFilesWritten is called, incrementing the
notify_list_changed_count for each observer. During the Teardown phase
of IndexedDBTest, all observers are cleared.
Consequently, when DidForceCloseForDeleteBucketData is called, no
observers remain to trigger OnIndexedDBListChanged and increment the
count. Therefore, the expected count has been decreased in the new
implementation.
Bug: 41348374, 324111895
Change-Id: Idac145cfe04a79434b9e5d541511aaeb97386e0c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6275787
Auto-Submit: Garima Chadha <garimachadha@microsoft.com>
Commit-Queue: Abhishek Shanthkumar <abhishek.shanthkumar@microsoft.com>
Reviewed-by: Steve Becker <stevebe@microsoft.com>
Reviewed-by: Abhishek Shanthkumar <abhishek.shanthkumar@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#1432173}
This change removes some usages of StorageType in QuotaManager.
After StorageType::kSyncable deprecation, all other storage types
except kTemporary are deprecated. So we no longer need to specify
StorageType. Further cleanup to remove usage in QuotaManager,
QuotaDatabase, etc. will follow.
Bug: 40211051
Change-Id: I8428a51ffc2a25781dacfffabae48de3032c6bf9
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6336951
Reviewed-by: Tsuyoshi Horo <horo@chromium.org>
Commit-Queue: Ayu Ishii <ayui@chromium.org>
Reviewed-by: Nate Fischer <ntfschr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1431654}
This change removes StorageType param from
QuotaManagerProxy::RegisterClient. After
StorageType::kSyncable deprecation, all other storage types
except kTemporary are deprecated. So we no longer need to
specify StorageType.
As a side-effect there is also clean-up in
BrowsingDataQuotaHelper to no longer collect syncable usage.
No storage data is associated with Syncable type now and will
always return 0.
Further StorageType cleanup from QuotaManager/QuotaDatabase
will be done in a follow-up change.
Bug: 40211051
Change-Id: I70cb64c7b270def02d8b539a77498eba208b1e4a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6309405
Reviewed-by: Bo Liu <boliu@chromium.org>
Reviewed-by: Martin Šrámek <msramek@chromium.org>
Reviewed-by: Tsuyoshi Horo <horo@chromium.org>
Reviewed-by: Hiroki Nakagawa <nhiroki@chromium.org>
Reviewed-by: Nasko Oskov <nasko@chromium.org>
Reviewed-by: Marijn Kruisselbrink <mek@chromium.org>
Commit-Queue: Ayu Ishii <ayui@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1429075}
This change removes some usages of StorageType in QuotaManagerProxy.
After StorageType::kSyncable deprecation, all other storage types
except kTemporary are deprecated. So we no longer need to specify
StorageType. Further cleanup to remove usage from QuotaManager,
QuotaDatabase, etc. will follow.
Bug: 40211051
Change-Id: Iba5caa5aefcc346cbcf9e7aac3f05ab33ca53d61
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6306646
Reviewed-by: Bo Liu <boliu@chromium.org>
Commit-Queue: Ayu Ishii <ayui@chromium.org>
Reviewed-by: Tsuyoshi Horo <horo@chromium.org>
Reviewed-by: Hiroki Nakagawa <nhiroki@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1426466}
The previous database cleaner (tombstone sweeper and db compaction)
used to occur only during database connection closure. This caused a
variety of performance issue where the tombstones could pile up within
the session or would not be cleaned as the browser would also close
when the connection closed.
This CL introduces a clean up routine which can run while the database
connection is active. The routine consists of both tombstone sweeping
and compaction, and will be triggered (after a delay) any time a cursor
encounters enough tombstones while iterating.
The task for clean up will be postponed if there are any active
transactions. We will also trigger the run regardless of oncoming calls
when an upper limit of the time has passed since the last run.
Bug: 374691835
Change-Id: I4596514086ccb1e045f573d25095c3f3cd273de2
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5948643
Reviewed-by: Abhishek Shanthkumar <abhishek.shanthkumar@microsoft.com>
Reviewed-by: Steve Becker <stevebe@microsoft.com>
Reviewed-by: Ayu Ishii <ayui@chromium.org>
Commit-Queue: Tanuj Martolia <tamartol@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#1418535}
The test case in the report fetches a blob from IDB and then creates
a new blob that contains that blob (as an array of length 1). Since
the IDB blob is wrapped in another blob, the blob registry effectively
adds a ref to the BlobDataItemReader connection. Then the javascript
blob which corresponds to the IDB blob is eventually garbage
collected*, which causes receivers_ to disconnect and then
`registry_blob_` to be unbound. Then the same blob is retrieved from
IDB again. BucketContext cleverly (or annoyingly) reuses the existing
BlobReader, but this time there's no placeholder registry blob left,
so when the page tries to create a nested blob yet again, the blob
registry errors out in a way that kills the tab process.
Fix this by re-establishing the placeholder blob when the new
mojo connection to the renderer is added. An alternative would be to
not reuse the BlobReader when serving different IDB queries.
*the issue reporter mentioned clicking "open file" 27 times, but the
key is just to do it a couple times then wait for GC to occur, then
one more time.
Bug: 392376370
Change-Id: Icaeac9bcbcda891a79f86c40469f1ab4e1d9b39c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6216397
Reviewed-by: Steve Becker <stevebe@microsoft.com>
Commit-Queue: Evan Stade <estade@chromium.org>
Reviewed-by: Abhishek Shanthkumar <abhishek.shanthkumar@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#1415908}
Crash stacks don't directly point at this method, but it seems that's a
result of code folding, i.e. some other function that also has a body
of just `NOTREACHED()` is in the crash stack. Thus, this seems like the
most likely culprit.
Still unclear from code inspection how this path would ever be triggered
but the new version should hopefully confirm the problematic function
and also not crash.
Bug: 390586616
Change-Id: I1b2883584aaac5c5b91c66945dfa5a7c2f300801
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6202351
Reviewed-by: Steve Becker <stevebe@microsoft.com>
Commit-Queue: Evan Stade <estade@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1411813}
This relands commit 60632268ea.
Difference to original: added support for AsDataPipeGetter and
extended blob-contenttype.any.js WPT to cover this case.
Original change's description:
> IDB: direct reads for blobs
>
> For the standard case of a page reading IDB data from the blob store,
> don't go through the blob registry on the i/o thread and instead
> connect the IDB bucket thread directly to the renderer.
>
> In some other (rarer) cases the blob registry is still used. This
> is accomplished by *additionally* registering a blob with
> BlobStorageContext using the same UUID, which is necessary for:
>
> * WriteBlobToFile(), which does lookup by UUID
> * loading data for a blob:// URL, i.e. mojom::Blob::Load, which is
> thunked through to the registry blob because implementation is non-
> trivial
>
> Bug: 373684390
> Change-Id: I9235f23303e4e6a05bf12a8acff32a5fb4e2a565
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6113789
> Commit-Queue: Evan Stade <estade@chromium.org>
> Reviewed-by: Steve Becker <stevebe@microsoft.com>
> Cr-Commit-Position: refs/heads/main@{#1400627}
Bug: 373684390
Change-Id: Ie555cf4b583b862d306c43e3e4be76e957ea6c5a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6138579
Reviewed-by: Steve Becker <stevebe@microsoft.com>
Commit-Queue: Evan Stade <estade@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1401872}
This reverts commit 60632268ea.
Reason for revert: causing crashes (see crbug.com/386615753)
Original change's description:
> IDB: direct reads for blobs
>
> For the standard case of a page reading IDB data from the blob store,
> don't go through the blob registry on the i/o thread and instead
> connect the IDB bucket thread directly to the renderer.
>
> In some other (rarer) cases the blob registry is still used. This
> is accomplished by *additionally* registering a blob with
> BlobStorageContext using the same UUID, which is necessary for:
>
> * WriteBlobToFile(), which does lookup by UUID
> * loading data for a blob:// URL, i.e. mojom::Blob::Load, which is
> thunked through to the registry blob because implementation is non-
> trivial
>
> Bug: 373684390
> Change-Id: I9235f23303e4e6a05bf12a8acff32a5fb4e2a565
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6113789
> Commit-Queue: Evan Stade <estade@chromium.org>
> Reviewed-by: Steve Becker <stevebe@microsoft.com>
> Cr-Commit-Position: refs/heads/main@{#1400627}
Bug: 373684390,386615753
Change-Id: I8e7460b58c175d9cbd62e99845dd68c71ef6dd06
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6132793
Auto-Submit: Evan Stade <estade@chromium.org>
Commit-Queue: Evan Stade <estade@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#1400977}
For the standard case of a page reading IDB data from the blob store,
don't go through the blob registry on the i/o thread and instead
connect the IDB bucket thread directly to the renderer.
In some other (rarer) cases the blob registry is still used. This
is accomplished by *additionally* registering a blob with
BlobStorageContext using the same UUID, which is necessary for:
* WriteBlobToFile(), which does lookup by UUID
* loading data for a blob:// URL, i.e. mojom::Blob::Load, which is
thunked through to the registry blob because implementation is non-
trivial
Bug: 373684390
Change-Id: I9235f23303e4e6a05bf12a8acff32a5fb4e2a565
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6113789
Commit-Queue: Evan Stade <estade@chromium.org>
Reviewed-by: Steve Becker <stevebe@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#1400627}
These metrics are intended to shed more light on some operations
that could be executing slowly, based on observed shutdown hangs.
Low-Coverage-Reason: temporary metrics for debugging
Bug: 384476946
Change-Id: I80f5227f320ba3652978e43aab51400b47ad756e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6120590
Reviewed-by: Brad Triebwasser <btriebw@chromium.org>
Commit-Queue: Evan Stade <estade@chromium.org>
Owners-Override: Evan Stade <estade@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1399966}
The following changed `content::indexed_db::OpenFileAndReadIntoPipe()`
behavior:
https://chromium-review.googlesource.com/c/chromium/src/+/5898304
Prior to the change, `OpenFileAndReadIntoPipe()` considered reading up
to N bytes as success. After the change, `OpenFileAndReadIntoPipe()`
must read exactly N bytes to succeed. When expecting more bytes,
`FileStreamReaderToDataPipe` reads the end of file instead, which is
handled differently than before.
Before:
After reading end of file, `FileStreamReaderToDataPipe::ReadMore()`
calls `OnComplete(result)`. `result` is 0 since it is end of file.
0 is also the status code for `net::OK`, which causes the read to
succeed.
After:
`FileStreamReaderToDataPipe::ReadMore()` calls
`OnComplete(net::ERR_FAILED)` in response to reading end of file.
The fix restores the original behavior and adds unit test coverage.
Bug: 383157185
Change-Id: I0b976252331209d0453cbef14be5b1e3b24e8c90
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6102095
Reviewed-by: Rahul Singh <rahsin@microsoft.com>
Commit-Queue: Steve Becker <stevebe@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#1398772}
Right now, tab freezing is based on the existence of an IndexedBD
connection. This is too conservative. Telemetry data shows that a
large number of tabs are opted-out of tab freezing because of
IndexedDB.
With this change, tabs are only opt-out if they are running
a IDB transaction that actually blocks another client. This is done
by refactoring the DisallowInactiveClient() functionality to also
handle frozen documents.
The existing ObservedFeatureType named kIndexedDBConnection is
renamed to kBlockingIndexedDBLock to track this scenario, which
is then used to opt-out the tab from freezing.
Bug: 362464956
Change-Id: If455789e900c232813d045b831e937a042a334c4
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5838043
Reviewed-by: Francois Pierre Doray <fdoray@chromium.org>
Commit-Queue: Patrick Monette <pmonette@chromium.org>
Owners-Override: Patrick Monette <pmonette@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1398627}
Before this CL, a client is inactive iff it is inside the BF cache.
To support freezing, IDBDatabase now listens for the
ContextLifecycleStateChanged notification, which invokes
DidBecomeInactive when the frame is frozen, just like when the
frame enters BFCache.
In addition, whenever a transaction ends, we check if any of the
remaining transactions are blocking other clients to determine if
the client is now eligible for freezing.
Bug: 362464956
Change-Id: I4d8092bef3189e4d42124c2cb169015570e5df96
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5958727
Commit-Queue: Charlie Reis <creis@chromium.org>
Commit-Queue: Patrick Monette <pmonette@chromium.org>
Reviewed-by: Evan Stade <estade@chromium.org>
Reviewed-by: Charlie Reis <creis@chromium.org>
Auto-Submit: Patrick Monette <pmonette@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1382575}
