kheina-com / Blue-Blocker

Blocks all Twitter Blue verified users on twitter.com
Mozilla Public License 2.0
321 stars 28 forks source link

Uncaught (in promise) Error: QUOTA_BYTES_PER_ITEM quota exceeded #272

Open bardware opened 2 months ago

bardware commented 2 months ago

When I unblock an account in Chrome browser, I get the message

Uncaught (in promise) Error: QUOTA_BYTES_PER_ITEM quota exceeded

in the console.

I am under the impression, the account is not put on the safe list but is queued for a block, again.

What is the issue?

rougetimelord commented 2 months ago

That sounds like the safelist being stored by the extension is getting too big, and Chrome is complaining. We currently use the sync StorageArea to store all of the data from the extension. There is a maximum size of 8192 bytes per item for that StorageArea.

Possible fixes:

  1. Add the unlimitedStorage permission to the extension manifest.
    • This would require using the local StorageArea instead of sync, which would mean that the data wouldn't sync between a user's devices.
  2. Only store the ID of unblocked users rather than the screen name.
    • This would make the safelist page harder to use. However, we could use the local StorageArea or a database to store usernames to make the safelist page work right.
    • Alternatively we could use a compressed data structure to store the safelist in sync, and a non-compressed one in local.
  3. Split the safelist into multiple storage items when we go over the item size limit.
    • We would have to keep track of all of the storage items that contain the safelist and pull them all for the safelist page. This might also run into the item limit (512) or total data quota (102400 bytes) eventually.
darukaru commented 2 months ago

Might help with narrowing it down: I've noticed this happening primarily with users who have emoji in their names.

kheina commented 2 months ago

@rougetimelord best solution here is probably what we did with the queue and history, move the safelist into an indexed db rather than sync storage. unfortunately this would also mean that it's not synced, which isn't great

rougetimelord commented 2 months ago

@rougetimelord best solution here is probably what we did with the queue and history, move the safelist into an indexed db rather than sync storage. unfortunately this would also mean that it's not synced, which isn't great

yeaaaa, I think the safelist is probably the most important setting to have synced across devices, so I have no idea