1733054 - Got an QuotaExceededError When my page's storage reach 5m

Status: RESOLVED FIXED

(Core :: Storage: Quota Manager, defect, P2)

Description

[Zach Miao]

Attachment: error.png

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:92.0) Gecko/20100101 Firefox/92.0

Steps to reproduce:

Open my web page in multiple tabs in 92.0.
When I open my page in new tab, the storage will increase 0.5m around every time
And when the storage reach 5m, then there will be an QuotaExceededError.
I check my sessionStorage and localStorage, they just have 100kb around.
And we can't reproduce this in 91.0.

Actual results:

The page can't be load anymore.

Expected results:

The page can load normally.
And Can you tell me the storage location in file system? (92.0.1)

Comment 1

[:Gijs (he/him)]

Doesn't look like this needs to be treated like a security exploit risk, so dropping that flag.

Comment 2

[Alex Turff]

This appears to be similar to 1673276 & 1733120

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:janv, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 4

[Jan Varga [:janv]]

I believe the usage will go down after 20 seconds of inactivity, but it seems we will have to adjust some internal constants.

Just to verify my theory, can you set this preference dom.storage.snapshot_reusing to false ?

Comment 5

[Zach Miao]

Yes, I have tried to set the 'dom.storage.snapshot_reusing' to false, and the storage will work well, and will not increase so quickly.

Comment 8

[jhuang]

Any sense of when a fix might be released? Thank you!

Comment 9

[u698539]

You can replicate this issue with a simple react app.

Create an empty react app.

npx create-react-app my-app --template typescript

Replace the content of App.tsx

import { default as prettyBytes } from 'pretty-bytes';
import React, { useEffect, useState } from 'react';
import './App.css';

const start = new Date();

function MemStats() {
  const [bytes, setBytes] = useState<number | undefined>(0);
  const [quota, setQuota] = useState<number | undefined>(0);
  const [seconds, setSeconds] = useState<number | undefined>(0);
  useEffect(() => {
    const interval = setInterval(() => {
      setSeconds(Math.round((+new Date() - +start) / 1000));
      localStorage.setItem('key', new Date().toISOString());
    }, 1000);
    return () => clearInterval(interval);
  }, []);
  useEffect(() => {
    const interval = setInterval(async () => {
      const estimate = await navigator.storage.estimate();
      setBytes(estimate.usage);
      setQuota(estimate.quota);
    }, 500);
    return () => clearInterval(interval);
  }, []);
  return (
    <span>
      {prettyBytes(bytes || 0)}/{prettyBytes(quota || 0)} - {seconds} seconds
    </span>
  );
}

function App() {
  return (
    <div className="App">
      <header className="App-header">
        <MemStats />
      </header>
    </div>
  );
}

export default App;

Run the app and see what happens when you open two tabs (quota is displayed within the app).

npm start

Comment 10

[jhuang]

Happy New Year!

Are there any programmatic way of working around this issue, or any chance of raising the priority of this issue?

Our code relies on constant access to localStorage api, which probably prevents the snapshot from being destroyed.

We don't have any issues when using the same code in other browsers.

Any workaround suggestions or a fix would be much appreciated.

Thank you!

Comment 11

[Rob Eberhardt]

I second raising the priority of this issue! This is affecting tens of thousands of users on a daily basis and they are very frustrated. I see that https://bugzilla.mozilla.org/show_bug.cgi?id=1681300 has a fix coming in v97, but that is still over a month away, and it is not clear that the fix will also resolve the issues reported in these other tickets (1673276, 1730644, 1733120, 1743219). Can we get a hotfix expedited for the current release? Please confirm if 1681300 will also resolve this issue, and if we can get the fix sooner. If 1681300 will not fix the issue for this ticket, please confirm which version will receive the fix and the expected ETA.

Comment 12

[Jan Varga [:janv]]

Let me see if we can get this fixed quickly.

Comment 13

[Jan Varga [:janv]]

Attachment: Bug 1733054 - Move calculations for peak usage pre-incrementation to the parent process; r=#dom-storage

Comment 14

[Jan Varga [:janv]]

Attachment: Bug 1733054 - Rename Timer to IdleTimer in LSSnapshot; r=#dom-storage

Depends on D135516

Comment 15

[Jan Varga [:janv]]

Attachment: Bug 1733054 - Introduce prefs for peak usage pre-incrementation and idle timeout; r=#dom-storage

Depends on D135517

Comment 16

[Jan Varga [:janv]]

Attachment: Bug 1733054 - Adjust prefs for peak usage pre-incrementation and idle timeout; r=#dom-storage

Depends on D135518

Comment 17

[Rob Eberhardt]

Hello Jan Varga, any update on this?

Comment 18

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/50c6e044a89f
Move calculations for peak usage pre-incrementation to the parent process; r=dom-storage-reviewers,asuth
https://hg.mozilla.org/integration/autoland/rev/c7304d6c6dd0
Rename Timer to IdleTimer in LSSnapshot; r=dom-storage-reviewers,asuth
https://hg.mozilla.org/integration/autoland/rev/2bce68aa9877
Introduce prefs for peak usage pre-incrementation and idle timeout; r=dom-storage-reviewers,asuth
https://hg.mozilla.org/integration/autoland/rev/b83364980212
Adjust prefs for peak usage pre-incrementation and idle timeout; r=dom-storage-reviewers,asuth

Comment 19

[Atila Butkovits]

https://hg.mozilla.org/mozilla-central/rev/50c6e044a89f
https://hg.mozilla.org/mozilla-central/rev/c7304d6c6dd0
https://hg.mozilla.org/mozilla-central/rev/2bce68aa9877
https://hg.mozilla.org/mozilla-central/rev/b83364980212

Comment 20

[jhuang]

Hi Jan Varga, thank you for your help on resolving this issue. Would we be able to test this in the Firefox nightly soon?

Comment 21

[Rob Eberhardt]

Glad to see this is resolved. Is it accurate that this fix won't be available to end-users until v98 is released on 2022-03-08? Or is it possible to get a patch before then? (https://wiki.mozilla.org/Release_Management/Calendar)

Comment 22

[Jan Varga [:janv]]

Yes, the fix is already in the current Nightly (which will become FF release 98), you can start testing it. If you previously changed the dom.storage.snapshot_reusing pref, please reset it to the default value (which is true).
If we get a positive feedback on the fix in current Nightly, we will request an approval for beta uplift (end users would see the fix in FF release 97).

Comment 23

[jhuang]

Just did a quick test with the Nightly build, it looks like the fix is working, thank you Jan!

Comment 24

[Rob Eberhardt]

Ditto! Tested and it looks great! Loaded over 70 tabs with no issues. Many thanks for the fix, and would love to see this approved for beta uplift!

Comment 25

[Jan Varga [:janv]]

Comment on attachment 9258349 [details]
Bug 1733054 - Adjust prefs for peak usage pre-incrementation and idle timeout; r=#dom-storage

Beta/Release Uplift Approval Request

• User impact if declined: Users hitting the 5MB limit prematurely.
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): The main change is about reducing some constants which affect how long we keep cached data in content processes and how much usage we pre-increment. The fix landed a week ago on mozilla-central. We also have a confirmation from users that the fix works for them well. There's a theoretical risk that reduced constants could regress the page load time, but that would be caught by our performance tests immediately after landing.
• String changes made/needed: None

Comment 26

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9258346 [details]
Bug 1733054 - Move calculations for peak usage pre-incrementation to the parent process; r=#dom-storage

Sorry, while I appreciate the impact this bug is having on users in some situations, we're unfortunately out of Beta builds for Fx97 this cycle in light of next week's RC. Given that this isn't a new issue in the 97 release and the limited time for testing and feedback before it ships, it's probably best for this to ride 98 to release.

Comment 27

[Rob Eberhardt]

[:RyanVM] - That is disappointing to hear and I think it should be reconsidered. This is causing daily issues at a VERY large company with a large Firefox user-base. There have already been plenty of people ditching Firefox as their default browser and switching to Chrome, and if they have to wait until March 8 for v98, there will be plenty more. If this cannot be approved for v97, then please consider making an immediate hotfix against v97 to v97.0.1.

Comment 28

[Ryan VanderMeulen [:RyanVM]]

As I said before, I understand that this is causing pain for people in some situations, but that has to be balanced against the risk of regressions affecting everyone else. We have little to no time for those issues to come to light in the current 97 cycle and this is an area where we've had issues in the past with regressions.

Comment 29

[Mathew Hodson]

Are you sure this doesn't affect ESR 91? The duplicate bug 1673276 was reported against Firefox 83.

Comment 30

[Ryan VanderMeulen [:RyanVM]]

LSNG didn't ride the trains until 92.

Comment 31

[blaskurain]

I believe this issue should be reopened since I can still reproduce it on 98.0a1 (2022-02-03) (64 bit) loading. Just load the following page in two tabs and you will see the disk usage grow as reported initially:

<!DOCTYPE html>
<html>
    <head>
        <meta charset="utf-8"/>
    </head>
    <body>
        <script>
(function() {
function saveData() {
    var s = 'x'.repeat((Math.round(Math.random() * 100000)));
    console.log('saveData ' + s.length);
    try {
        window.localStorage.setItem('x1', s);
    } catch (error) {
        console.log('Error: ' + error);
    }
}
window.localStorage.clear();
window.setInterval(saveData, 1500);
})();
        </script>
    </body>
</html>

Comment 32

[Jan Varga [:janv]]

How much data were you able to store ?

Comment 33

[blaskurain]

If you have a closer look at the test script you will see that I repeatedly store up to 100000 bytes always using one and the same key so disk usage should never be greater that 100K. On nightly it takes a couple of minutes to reach the quota. If you raise the frequency of the saveData calls it will reach is sooner. Even with very small sizes of s it will eventually run out of storage space.

It is thus not a matter of how much data I store: the amount of data is bound, but for some reason firefox needs an unbound amount of disk space to store it.

I can only reproduce the issue using at least two tabs so it seems somehow related to the concurrent access to the storage. Whether firefox is really using all this disk space for nothing or only the computation of the quota is done wrong is beyond me.

Comment 34

[Jan Varga [:janv]]

Ok, thanks for the detailed description, I'll try to reproduce it locally.
Anyway, this looks like a different bug.

Comment 35

[blaskurain]

All right, should I open a new bug report then or will you take care of it if you consider it necessary?

Comment 36

[Ladislav Brychta]

I must report the same bug like blaskurain. This affect not only one web but all webs across the domain. It looks like Firefox sums together amount of inserted localStorage data in every tab even if it is the same localStorage key on the same domain. When we check how much localStorage data we have stored, it is allways only some small kilobytes but we store and read data every second.

Comment 37

[Jan Varga [:janv]]

It seems I can't reproduce the issue with the script from comment 31. Maybe your group (eTLD+1) usage is already close to the limit ?
Could you run await navigator.storage.estimate(); in Web Developer Tools ?

Comment 38

[Ladislav Brychta]

I try this script too .. 5 tabs, the same script, open dev console in all tabs, cca 2 minutes running

In FF 96.0.3 (64 bitů)
Error: QuotaExceededError: The quota has been exceeded.
await navigator.storage.estimate();
quota: 2147483648
​usage: 9948005

In FF 98.0a1 (2022-02-06) (64 bitů)
Error: QuotaExceededError: The quota has been exceeded.
await navigator.storage.estimate();
quota: 10737418240​
usage: 5429172

Comment 39

[blaskurain]

(In reply to Jan Varga [:janv] from comment #37)

It seems I can't reproduce the issue with the script from comment 31. Maybe your group (eTLD+1) usage is already close to the limit ?
Could you run await navigator.storage.estimate(); in Web Developer Tools ?

The key to reproduce the issue is using at least 2 tabs, just in case you didn't take this into account. I would also like to remark again that the script from comment #37 uses a bounded amount of storage. To the best of my knowledge usage should never grow.

Comment 40

[Jan Varga [:janv]]

I tried with 2 tabs and also with 5 tabs, but I tested only on my Mac so far.
Jari, could you try to reproduce it on Windows ?

Comment 41

[Jan Varga [:janv]]

Attachment: testcase

Comment 42

[Jan Varga [:janv]]

Oh, I see it on Windows, let me debug it.

Comment 43

[Ladislav Brychta]

(In reply to Jan Varga [:janv] from comment #42)

Oh, I see it on Windows, let me debug it.

Yes, we have this problem on Windows 10 and on different versions of Linux.

Comment 44

[blaskurain]

I am experiencing the problem personally on Ubuntu 20.04.3 both with nightly and with the distribution's version (96.0 64 bits). I have reports of the issue on several Windows versions but regrettably I don't have a detailed list of them at hand.

Comment 45

[Jari Jalkanen]

For what it's worth, I also see it on Windows with a recent Nightly build.

Comment 46

[Jan Varga [:janv]]

I think I know what' going on and I have a fix in testing.

Comment 47

[Jan Varga [:janv]]

I filed a new bug 1754448 for the other issues.

Comment 48

[Jan Varga [:janv]]

The most important fixes for bug 1754448 have landed, so the problem with multiple tabs should be now fixed for real.

Comment 49

[Ladislav Brychta]

(In reply to Jan Varga [:janv] from comment #48)

The most important fixes for bug 1754448 have landed, so the problem with multiple tabs should be now fixed for real.

Thank you very much .. Is there an estimate of how long it will take to get into a version?

Comment 50

[Jan Varga [:janv]]

It's fixed in FF 99. I'm afraid the fixes are too complex so they wouldn't be approved for a beta uplift (FF 98).

Comment 51

[blaskurain]

Just checked on nightly and everything seems fine. Thank you! Pity thought it won't make into FF 98.

Comment 52

[Marius Tarlo]

Hello,

We're affected with this bug on Firefox ESR 91
We thought that it would be fixed with ESR 91.7 (corresponding to FF 98) but it's not
I guess that you should "uplift" the fix to the ESR branch?

Thank you very much

Comment 53

[Mike Kaply [:mkaply]]

Is there any way to do a version of this fix that could go on the ESR?

Comment 54

[Jens Stutte [:jstutte]]

(In reply to Mike Kaply [:mkaply] from comment #53)

Is there any way to do a version of this fix that could go on the ESR?

Jan, WDYT?

Comment 55

[Jan Varga [:janv]]

Ok, I can try to apply all these patches on current ESR, but we will need bug 1754448 as well.

Comment 56

[Jan Varga [:janv]]

ESR contains the fix now.