a7c2f79a94
* test: update DOM storage quota limits test * fix: update dom_storage_limits.patch (fixes #13465) The previous version of this patch did not include changes required to circumvent the quota enforcement performed by StorageAreaImpl. Consequently when the quota was exceeded, things still "appeared to work" at first but then would later fail silently. That is, the cache would be updated but the backing store would not. This could be fixed by disabling the code below (from `content/browser/dom_storage/storage_area_impl.cc`) ``` // Only check quota if the size is increasing, this allows // shrinking changes to pre-existing maps that are over budget. if (new_item_size > old_item_size && new_storage_used > max_size_) { if (map_state_ == MapState::LOADED_KEYS_ONLY) { receivers_.ReportBadMessage( "The quota in browser cannot exceed when there is only one " "renderer."); } else { std::move(callback).Run(false); } return; } ``` However, since this seems to have some unintended side-effects (see updated notes in dom_storage_limits.patch) it seems more prudent to simply increase the quota to a larger yet still reasonable size rather than attempt to circumvent the storage quota altogether. |
||
---|---|---|
.. | ||
configs | ||
fixtures | ||
static | ||
ts-smoke | ||
.eslintrc | ||
api-clipboard-spec.js | ||
api-native-image-spec.js | ||
api-process-spec.js | ||
api-remote-spec.js | ||
api-shell-spec.js | ||
api-web-frame-spec.js | ||
asar-spec.js | ||
BUILD.gn | ||
chromium-spec.js | ||
events-helpers.js | ||
expect-helpers.js | ||
node-spec.js | ||
package.json | ||
spec-helpers.js | ||
webview-spec.js | ||
yarn.lock |