Make livemarks more resilient to storage.sync quota enforced in Firefox 79

[JcKlomp]

Add-on version Add-on version: 2.8

Describe the bug After upgrading to Firefox 79.0 (Linux) all livemarks are gone from the add-on. The created bookmarks are still available but they do not get updated and all feeds are gone from the add-on page. After downgrading (in my case to Firefox 69.0.1 due package availability of the Fedora repository) the livemarks work as expected again (they are updated and are visible in the add-on page). This allows for exporting them so that they can be imported in Firefox 79, which is necessary because after upgrading all livemarks are gone again. Importing does not restore the directory structure so it is a bit of a messy (one time?) fix (all my livemarks are in the RSS bookmarkbar directory and are then subdivided into a couple of subdirectories).

[nt1m]

Hi, thanks for reporting! Could you please check if you're not affected by this CCleaner issue: https://github.com/nt1m/livemarks/issues/263 ?

[JcKlomp]

I'm using Linux, I don't use CCleaner. Also the symptoms are not similar since the livemarks were back on downgrade. I tried to reproduce it on a separate installation but couldn't, so it probably is something in my Firefox profile.

[nt1m]

Ah, looks like you might be hitting the newly enforced quotas for sync storage unfortunately. https://blog.mozilla.org/addons/2020/07/24/extensions-in-firefox-79/ (Thanks mkaply for pointing this out). Sorry about that.

I'll see what I can do something about it.

[evilpie]

Weird. I thought that we actually don't use that much storage per feed.

[JcKlomp]

I am using Firefox sync and on the test box where I tried to reproduce I don't so if it is a issue with storage.sync quota then that would check out. Before I moved to livemarks I did have a huge amount of feeds, but now that I'm using livemarks I brought it down to 34 feeds. Doesn't look like a very big number to me but maybe it does trigger it somehow. Is there a way to tell that what I'm seeing really is an issue with storage.sync quota?

[evilpie]

You could test the following.

1. Goto about:debugging#/runtime/this-firefox
2. Click the "Inspect" button next to "Livemarks"
3. Goto the "Console" tab.
4. Execute await browser.storage.sync.getBytesInUse()

That should tell us how much storage Livemarks is using. Thanks!

[JcKlomp]

In the mean time I have cleaned up all the stale bookmark feed, so this is what I get now for the imported feeds:

await browser.storage.sync.getBytesInUse()
5806

Doesn't seem like a lot judged by this: https://searchfox.org/mozilla-central/rev/8d55e18875b89cdf2a22a7cba60dc40999c18356/toolkit/components/extensions/schemas/storage.json#314-325

[evilpie]

Yeah, maybe it's an unrelated storage problem. MDN also lists some of the limits, none of which we should be hitting: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/storage/sync#Storage_quotas_for_sync_data

[rpl]

@evilpie this may be related to Bug 1659053 - Updating from 78.0.2 to 79.0 corrupts add-ons, add-on settings, which is a Quota Manager initialization issue. In Bug 1659053 Comment 5 (and the comments that follows) that are info about other details that can be collected to double-check if the issue reported here may be due to Bug 1659053.

[JcKlomp]

I looked at mozbz#1659053 and it does not turn up any signs that something is wrong for me. After updating to FF80 everything still seems fine, so I don't know how serious this is. The export (after downgrade) and import of the feeds resolved the issue for me, unless it happens more often I think from my side this issue no longer needs to be left open (though I see the subject has been generalised). Perhaps periodic automatic feed exports could be an easy method to more easily work around such an issue in the future.