mirrors/electron
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
electron/patches/chromium/dom_storage_limits.patch

48 lines
2.3 KiB
Diff
Raw Normal View History

fix: bypass DOM storage quota (#15596)
2018-11-12 17:19:01 +00:00
From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
From: Jacob Quant <jacobq@gmail.com>
fix: prevent silent failure when DOM storage quota exceeded (#20899) * 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.
2019-11-22 19:35:54 +00:00
Date: Thu, 31 Oct 2019 14:00:00 -0500
fix: bypass DOM storage quota (#15596)
2018-11-12 17:19:01 +00:00
Subject: dom_storage_limits.patch
fix: prevent silent failure when DOM storage quota exceeded (#20899) * 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.
2019-11-22 19:35:54 +00:00
This patch increases the DOM storage (e.g. `localStorage`
and `sessionStorage`) size quota from 10MiB to 100MiB.
Previous versions of this patch attempted to circumvent
the restriction altogether.
However, this can lead to other problems, such as crashing
the Dev Tools when attempting to read or write values that exceed
`IPC::Channel::kMaximumMessageSize` (128MiB).
fix: bypass DOM storage quota (#15596)
2018-11-12 17:19:01 +00:00
fix: prevent silent failure when DOM storage quota exceeded (#20899) * 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.
2019-11-22 19:35:54 +00:00
Increasing the quota rather than bypassing it reduces the
amount of chromium code that needs to be changed for Electron
as well as keeps these storage areas limited to a bounded
size meanwhile giving application developers more space to work with.
fix: bypass DOM storage quota (#15596)
2018-11-12 17:19:01 +00:00
chore: bump chromium to f755b70e34659441e72c1a928a406 (master) (#21000)
2019-12-11 00:22:35 +00:00
diff --git a/components/services/storage/dom_storage/dom_storage_constants.cc b/components/services/storage/dom_storage/dom_storage_constants.cc
chore: bump chromium to 108.0.5329.0 (main) (#35628) Co-authored-by: Samuel Attard <sattard@salesforce.com> Co-authored-by: VerteDinde <vertedinde@electronjs.org> Co-authored-by: Keeley Hammond <khammond@slack-corp.com> Co-authored-by: Jeremy Rose <jeremya@chromium.org>
2022-10-03 20:21:00 +00:00
index aa5edd1d07d97bee4912b14996ff804351240e94..8334b7eb6a3293c068f5234508f8dca780ccb262 100644
chore: bump chromium to f755b70e34659441e72c1a928a406 (master) (#21000)
2019-12-11 00:22:35 +00:00
--- a/components/services/storage/dom_storage/dom_storage_constants.cc
+++ b/components/services/storage/dom_storage/dom_storage_constants.cc
@@ -6,7 +6,9 @@
namespace storage {
feat: Upgrade to Chromium 71.0.3578.98 (#15966)
2019-01-12 01:00:43 +00:00
fix: prevent silent failure when DOM storage quota exceeded (#20899) * 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.
2019-11-22 19:35:54 +00:00
-const size_t kPerStorageAreaQuota = 10 * 1024 * 1024;
+// Electron's dom_storage_limits.patch increased this value from 10MiB to 100MiB
+const size_t kPerStorageAreaQuota = 100 * 1024 * 1024;
chore: bump chromium to f755b70e34659441e72c1a928a406 (master) (#21000)
2019-12-11 00:22:35 +00:00
+
const size_t kPerStorageAreaOverQuotaAllowance = 100 * 1024;
feat: Upgrade to Chromium 71.0.3578.98 (#15966)
2019-01-12 01:00:43 +00:00
chore: bump chromium to f755b70e34659441e72c1a928a406 (master) (#21000)
2019-12-11 00:22:35 +00:00
} // namespace storage
fix: prevent silent failure when DOM storage quota exceeded (#20899) * 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.
2019-11-22 19:35:54 +00:00
diff --git a/third_party/blink/public/mojom/dom_storage/storage_area.mojom b/third_party/blink/public/mojom/dom_storage/storage_area.mojom
chore: bump chromium to 108.0.5329.0 (main) (#35628) Co-authored-by: Samuel Attard <sattard@salesforce.com> Co-authored-by: VerteDinde <vertedinde@electronjs.org> Co-authored-by: Keeley Hammond <khammond@slack-corp.com> Co-authored-by: Jeremy Rose <jeremya@chromium.org>
2022-10-03 20:21:00 +00:00
index 332be0811d86c7a265f440ab7719460160a22617..e3382d843599ef6017e0ac557919b3a41809f17d 100644
fix: prevent silent failure when DOM storage quota exceeded (#20899) * 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.
2019-11-22 19:35:54 +00:00
--- a/third_party/blink/public/mojom/dom_storage/storage_area.mojom
+++ b/third_party/blink/public/mojom/dom_storage/storage_area.mojom
chore: bump chromium to 5b340c815ce15ab2efcf277ed19e9 (master) (#22064) Co-authored-by: Shelley Vohr <shelley.vohr@gmail.com> Co-authored-by: Samuel Attard <samuel.r.attard@gmail.com> Co-authored-by: loc <andy@slack-corp.com> Co-authored-by: Robo <hop2deep@gmail.com> Co-authored-by: Jeremy Apthorp <nornagon@nornagon.net>
2020-03-03 21:35:05 +00:00
@@ -50,7 +50,8 @@ struct KeyValue {
fix: prevent silent failure when DOM storage quota exceeded (#20899) * 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.
2019-11-22 19:35:54 +00:00
interface StorageArea {
// The quota for each storage area.
// This value is enforced in renderer processes and the browser process.
- const uint32 kPerStorageAreaQuota = 10485760; // 10 MiB
+ // Electron's dom_storage_limits.patch increased this value from 10MiB to 100MiB
+ const uint32 kPerStorageAreaQuota = 104857600; // 100 MiB
update dom storage quota patch https://chromium-review.googlesource.com/c/chromium/src/+/1166218/
2019-01-11 19:48:27 +00:00
fix: prevent silent failure when DOM storage quota exceeded (#20899) * 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.
2019-11-22 19:35:54 +00:00
// In the browser process we allow some overage to
// accommodate concurrent writes from different renderers
Reference in a new issue Copy permalink