I believe it depends on the available disk space. Do you have a lot of disk space (more than 10% if I am not mistaken)?

Does not 2.5 GB free from 35 GB suffice? It is less than 10%, but I had this state at least more than a year and everything was OK till lately. Maybe this is an edge state or some quota strictness changed in the Chrome.

vsemozhetbyt@ Could you please provide any sample test case file to test this issue from chrome-TE end?

Thanks!

brajkumar I do not really think this would be useful: the scripts are long, complicated an messy and they work correctly most of the time. The problem is flaky and hard to catch/predict.

However, here is one of the scripts for Tampermonkey: it detects the last post on Twitter, Facebook, etc. and saves its identifier in the IndexedDB. The next time it fetches this identifier and scrolls the page till this post and marks all the posts after the saved. Also, it provides simple navigation from post to post.

But you can use any simplified scripts with IndexedDB manipulation. For me, all IndexedDB data is wiped completely for all the sites and from all my user scripts at once.

Deleted: news_bmk.js 9.2 KB

news_bmk.js 9.2 KB View Download

Thank you for providing more feedback. Adding requester "brajkumar@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

As per comment #5 this issue is flaky and difficult to reproduce it from chrome-TE end, hence adding appropriate label for further triage.

dmurph@ Could you please take a look in to this issue?

Thanks!

Hello!

I think this may be an eviction. We probably don't want to be mass-clearing all IndexedDB databases.

vsemozhetbyt@ - can you do the following?

1. Restart your browser (so we have a clean state).
2. Wait until this happens again.
3. go to about://histograms and either attach that whole file, or just the histograms that have "Quota" or "IndexedDB" in the name. Maybe throw in "LevelDB" ones for good measure as well.

This should tell us if:
1. This was a indexeddb corruption / leveldb error or
2. If this might be a mass quota eviction w/ clues as to why.
3. neither of those :/

Note for others, here is the eviction logic:
https://cs.chromium.org/chromium/src/storage/browser/quota/quota_temporary_storage_evictor.cc?dr=CSs&l=166

Thank you for looking into it.

About a month ago, I've redistributed the partitions of my hard drive so that the c: partition can have more than 10% free space (4.8 GB of 42 GB now). Since then, I had no issues with the IndexedDB in my scripts, so I could not reproduce the problem. Maybe it really was the quota issue. Thank you for the tip.

Thank you for providing more feedback. Adding requester "dmurph@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Ok. Yeah eviction is what I suspect then. Choosing our eviction behavior when we get close to a full disk is really difficult. For web developers, they understand that websites use storage and would probably want IndexedDB databases / web storage to be able to get really close to a full disk. But for non-developer users, they mostly don't understand that websites can save more than a trivial amount of data to disk. So we're pretty careful about not being the 'cause' of a disk being full and work to evict anything we can before that happens.

Sorry for causing you pain here - it's pretty subtle behavior due to this difficult problem.