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
index 3fd108c89c3b070a08790850db4dfd6cc8a3ce44..c393f51709efd8b28b07edfe452d2b84b14983ae 100644
--- 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 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
index c9f9124eb6f4900988ad63fa38a03b7b6c5d1abb..9cba4e5af9a624d358697d806f151ee3998f0b58 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