Tabs stop grouping and moving to the beginning

[leo8nardo8]

Hey, It's feeling a little buggy last days.

Tabs are still getting tagged but it no longer grouping by category and grouping at the begins.

Behavior

Wanted

[dhallam]

I'm seeing issues too. In Chrome 92.0.4515.159 on Ubuntu 21.04 it's no longer bunching up tabs into their groups. It's adding tabs to a new instance of a group so all the groups have just 1 tab in them (except the one on the left for some reason).

[dhallam]

NB: I just resolved my above issue by copying the configuration out of bulk edit into a text editor, disabling the extension, manually ungrouping everything, re-enabling the extension, and pasting the configuration into bulk edit. Everything came back as expected.

[leo8nardo8]

It works! Thanks.

[jdhayford]

@dhallam @leo8nardo8 Glad the bulk edit ability helped you somewhat here. I have not experienced this problem, did either of you see anything that could help identify the cause?

[0xC0ncord]

@dhallam @leo8nardo8 Glad the bulk edit ability helped you somewhat here. I have not experienced this problem, did either of you see anything that could help identify the cause?

I also see this behavior. I see it most often when re-opening an older or existing session in Chromium, which doesn't cause all the tabs to load immediately. Unloaded tabs seem to be unsorted, and when they are loaded they will move into a new group. Loading all of the tabs causes them to move into this new group of loaded tabs until every unloaded tab is loaded, and the group containing the unloaded tabs is emptied.

[bsell93]

@jdhayford I think I figured out the issue here! It turns out Chrome sync storage has a max number of items. Google Docs

I just started having this problem this morning. So after a bunch of console logs, I ended up logging chrome.runtime.lastError in the get method and got this in my console numerous times Unchecked runtime.lastError: MAX_ITEMS quota exceeded

Investigating a potential fix. My guess is we need to clear the sync storage after a certain amount of time or on certain events.

Let me know if you have any thoughts @jdhayford

[bsell93]

@jdhayford this SO post suggests storing in local. Which we could for just the Group data. I don't see much gain in storing those key/value pairs in sync storage. Benefit of that is we can add "unlimited" storage request for local. We really should be cleaning up the keys periodically so I feel like the local storage option alone is the best solution. Would be a good solution until we find the best way to clean up the unused keys https://stackoverflow.com/a/29732624/4965713

[jdhayford]

@jdhayford this SO post suggests storing in local. Which we could for just the Group data. I don't see much gain in storing those key/value pairs in sync storage. Benefit of that is we can add "unlimited" storage request for local. We really should be cleaning up the keys periodically so I feel like the local storage option alone is the best solution. Would be a good solution until we find the best way to clean up the unused keys https://stackoverflow.com/a/29732624/4965713

Yeah great finds Bryant! I too recently discovered that some items are definitely "leaking" so to speak. I was originally considering the periodic cleanup job (comparing against window ids that still exist to avoid removing relevant items). Switching the groups to local makes perfect sense though and should also help give us much bigger margin.

I think creating a simple cleanup task will be good as a first step, that way if we do switch to local we can know that we aren't leaving user's sync storage too full in case we want to use that for later functionality.