Keeping the profile folder on a small sized drive break some websites.
Categories
(Core :: Storage: Quota Manager, defect, P3)
Tracking
()
People
(Reporter: kzyswd, Unassigned)
Details
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:87.0) Gecko/20100101 Firefox/87.0
Steps to reproduce:
Create the profile folder on a small sized drive (200-300MB)
Actual results:
At some point, some websites become inaccessible. From my observation it has something to do with "site data" and how FF stores its data.
One well know website is Gmail. In Gmail's case accessing gmail will return a blank page. When I click "Gmail" from google.com it does nothing. I just doesn't connect at all.
In order to fix it, I need to clear "site data" of the affected website. More on this later.
Expected results:
Website does not become inaccessible without having to delete site data.
Additional information:
As far as I remember I had this problem since about a year ago. At first I only had the problem with Gmail but it turned out it was not the only website affected. Then I did some testing.
When the profile folder was kept on a large drive this problem did not occur.
Next, I moved the profile folder from the small drive to a larger drive when the problem occured WITHOUT clearing "site data". As soon as I moved it to a larger drive, the affected site became accessible. Moving the profile folder back to the smaller drive made it inaccessible again.
Another thing I tried when the problem occured is to clear "site data" for NON-affected websites with the purpose of opening up space. If I deleted enough "site data", the affected website became accessible without having to delete the "site data" of the affected website itself.
From these results Im suspecting the way FF handles "site data" at high disk usage doesnt clear enough of the old data (if that is a thing) and prevents new data to be written, creating problems with websites that needs to store new data for it to work. I had the profile folder on small drive setting for years without problem so something could have changed around early version 70's.
This could also happen with people with a large but nearly full drive, though that has not been tested. For the smaller sized drive of 200-300MB, the problem started to happen when the drive usage reached around 60-70%.
Moving this to a potential component regarding Local Storage, if this is not the correct one move it over.
|
||
Comment 3•3 years ago
•
|
||
Yes, this is likely due to the small disk size for the profile and when QuotaManager triggers data clearing due to storage pressure interacting with some limitations in how Firefox deals with broken Service Workers (that will have fixes landing very soon). Firefox's heuristics for providing offline storage for sites are documented here on MDN.
Firefox's behavior hasn't changed here, but it's likely that sites' behavior has changed. Many large sites are now using ServiceWorkers to provide for offline support and potentially improve performance on slow networks. Many sites that do complicated things seem to generally assume that they can use several hundred megabytes of storage without checking what their quota allocation is. (Ex: Slack seems to want to use up to 900 MiB over time.) Sites are also increasingly moving to using ServiceWorkers. I would suggest toggling the preference dom.serviceWorkers.enabled to false in your profile and going to about:serviceworkers to remove existing ServiceWorker registrations. (Clearing data for an origin will also clear its ServiceWorker registrations). This should stop gmail from using a ServiceWorker and the corresponding storage, but will potentially degrade the UI that gmail serves you. This doesn't completely disable storage like IndexedDB and such, but it does seem like sites are frequently tying their more aggressive offline usage to ServiceWorkers.
That said, it's likely that our behavior on extremely small disk partitions, especially as it relates to data clearing, could be improved.
In general, I would advise using a larger profile size when using JS-heavy sites that potentially use offline storage. It's clear that most of the sites are developed assuming bountiful disk space for offline storage with very few checking the quota allocations they are given.
|
||
Updated•3 years ago
|
I would suggest toggling the preference dom.serviceWorkers.enabled to false
This has been a great workaround so far.
Hopefully with some improvements I can enable it back.
Description
•