Bugzilla

Hi there, thank you for the thorough report! I agree that the low limits are a stumbling block to using this API, and it’s the kind of thing that extensions might not be prepared to handle.

The low quota limits are the same as [Chrome’s implementation](https://developer.chrome.com/extensions/storage#property-sync). I think our worry with having a higher limit was that extensions coded against Firefox wouldn’t work when used in Chrome, but I wonder if there’s a middle ground here. Firefox Sync does have quota limits for other data types (bookmarks, history pages, tabs, saved passwords), too, for the reason you mentioned—reducing bandwidth and storage costs—but they’re higher than the `storage.sync` limits. On the one hand, requiring extensions to use their own backend when they want to store more than 100k of data (or 8k per value) feels like a big increase in effort and complexity. On the other, I think those extensions already have to do that for Chrome, today.

Before 79, we only had a server-side quota, though it wasn’t enforced by Firefox—so `storage.sync.set` would appear to succeed, and even save the data locally. In some ways, this was better, because extensions that used `storage.sync` for local storage (IOW, treating it exactly like `storage.local`) would continue to work. But it was worse overall, because that data wouldn’t sync, and neither the extension nor the user had any way to know that. Since the old Kinto limits were (I think) per-user, one extension that stored too much data could prevent all of them from syncing. There’s some more details about that in bug 1422673 and [this GitHub issue](https://github.com/mozilla/notes/issues/791).

So I’m not sure if we can bump the limits or if this will end up being a `WONTFIX`, but thanks for taking the time to file this!

Hi there, thank you for the thorough report! I agree that the low limits are a stumbling block to using this API, and it’s the kind of thing that extensions might not be prepared to handle.

The low quota limits are the same as [Chrome’s implementation](https://developer.chrome.com/extensions/storage#property-sync). I think our worry with having a higher limit was that extensions coded against Firefox wouldn’t work when used in Chrome, but I wonder if there’s a middle ground here. Firefox Sync does have quota limits for other data types (bookmarks, history pages, tabs, saved passwords), too, for the reason you mentioned—reducing bandwidth and storage costs—but they’re higher than the `storage.sync` limits. On the one hand, requiring extensions to use their own backend when they want to store more than 100k of data (or 8k per value) feels like a big increase in effort and complexity. On the other, I think those extensions already have to do that for Chrome, today.

Before 79, we only had a server-side quota, though it wasn’t enforced by Firefox—so `storage.sync.set` would appear to succeed, and even save the data locally. In some ways, this was better, because extensions that used `storage.sync` for local storage (IOW, treating it exactly like `storage.local`) would continue to work. But it was worse overall, because that data wouldn’t sync, and neither the extension nor the user had any way to know that. Since the old Kinto limits were (I think) per-user, one extension that stored too much data could prevent all of them from syncing. There’s some more details about that in bug 1422673 and [this GitHub issue](https://github.com/mozilla/notes/issues/791).

So I’m not sure if we can bump the limits, introduce a Firefox-specific “more storage” permission, or if this will end up being a `WONTFIX`, but thanks for taking the time to file this!