Bug 208438 – IndexedDB Regression: excessive storage consumed iPadOS 13.3.1

• Status: NEW
• Component: New Bugs

[Eddie Newitt]

Excessive storage is consumed when inserting IndexedDB data. It seems to depend on volume and transaction size.

e.g. saving 500MB worth of simple text data will result in a consumption of 1350MB of storage.

This behaviour can be reproduced easily in Safari;

1) Check storage & note consumption value (Settings>General>iPad Storage>Safari : Documents & Data)
2) Visit https://demo.agektmr.com/storage/ and insert ~500MB worth of IndexedDB data as 1000 x 500.0KB chunks
3) Accept any additional storage request prompts
4) Check storage consumption value again

If this doesn't reproduce the issue, try different chunk sizes (e.g. 10000 x 50KB)

Tested on A1709 iPad Pro iPadOS 13.3.1

[Radar WebKit Bug Importer]

<rdar://problem/59950145>

[Ben Nham]

This site appears to add X rows that are each Y MB in size to a table with no indices and an auto-incrementing primary key. (In the bug report X = 1000 and Y = 500 KB => 500 MB of expected disk usage.)

I can't repro excessive disk space usage when using an erase-installed 17D50 (iOS 13.3.1) device. What I do see is that the WAL file does not checkpoint properly into the main DB file since it is 500 MB large after running the test:

-rw-r--r--  1 mobile  mobile   4.0K May  8 14:19 IndexedDB.sqlite3
-rw-r--r--  1 mobile  mobile   1.0M May  8 14:21 IndexedDB.sqlite3-shm
-rw-r--r--  1 mobile  mobile   512M May  8 14:21 IndexedDB.sqlite3-wal

Inserting a subsequent 10k rows each 50KB each does bring up the storage prompt, but that is expected since the additional 500 MB of usage on top of the existing 500 MB puts you over the default 1 GB quota for per-origin storage usage.

The issue with the WAL file not checkpointing can lead to excessive space usage and has been fixed in https://bugs.webkit.org/show_bug.cgi?id=202137.