When the browser is closed, tabs left in closed groups are as a new tab (clean/empty)

[szojusz]

Hi I'm happily using the plugin because it keeps Chromium from eating up all the RAM but yesterday I discovered that the tabs that were in closed groups have become new blank tabs. Today I left the browser on the yellow group that was open and as you can see in the picture they didn't turn into new tabs and all the others are new tabs. Yesterday I rolled back all the farts to the state that they were Suspend loaded them all and Suspend again and as you can see it had no effect. Hopefully it can be fixed it has been occurring for a max of a week because before that I looked and everything was fine.

Browser: Brave Wersja 1.75.178 Chromium: 133.0.6943.98 (Official version) (64-bitowa)

Translation PL > EN by Deepl

[sergey-drpa]

Thank you for issue feedback!
I'll try to reproduce this behaviour..

[habmalnefrage]

Even in google chrome this behaviour occurs. All tabs in hidden tab groups were replaced by a "new tab". No possibility to unsuspend or even restore them. With this issue I lost 54 tabs including the tab history.

[szojusz]

With me, I can go back with the arrow to the "previous page", i.e. the suspended page, and they can still fire it up normally, but they are empty again after closing, but they have a history

[habmalnefrage]

with me, the "new tabs" have no more "previous page". They look like real "new tabs". Something destroyed the tab-history in the previously suspended tabs and now "new tab".

Maybe someone has an idea how to restore the tabs and their tab history which crashed.
Maybe when these exception issues are repaired the tabs and the tab history will come back. I do hope so.

[marcelosuzumura]

It's happening with me for some time, currently with official Chrome v134.0.6998.46.
At least I can use the browser "back" button and can go back to the suspended tab; it then works as usual.

[7fantasy7]

Please add at least an option to ignore grouped tabs for suspending, as it's done for auto-closing

[sergey-drpa]

Please add at least an option to ignore grouped tabs for suspending, as it's done for auto-closing

Added new Option in settings: Ignore Tabs in Group (from being suspended) in new early release: https://github.com/sergey-drpa/Tab-Suspender/releases/tag/2.0.7

• Added additional fix for blank tabs in groups

[szojusz]

I’m back again because it’s happening once more

Brave 1.91.168, Chromium 149.0.7827.54
Tab Suspender 2.0.12

I open the browser this morning, look at the group, and it’s full of new tabs, so the problem has returned.

I submitted

Please add at least an option to ignore grouped tabs for suspending, as is done for auto-closing

Added new Option in settings: Ignore Tabs in Group (from being suspended) in new early release: https://github.com/sergey-drpa/Tab-Suspender/releases/tag/2.0.7

• Added additional fix for blank tabs in groups

and the same effect as when they were suspended, and I don’t see the point in keeping over 60 tabs loaded in the background

Unfortunately, changing the Restore and StartUp settings didn’t help, so I disabled the extension and everything is working properly

[oLucasAguilar]

Confirming this still happens on Brave (Chromium 149) with Tab Suspender 2.0.12 on Linux. I had ~140 suspended tabs across 11 saved tab groups, and after a restart almost all of them came back as chrome://newtab/.

The reason I'm posting: I managed to recover them, so if this happens to you, your URLs are very likely still sitting on disk.

Quick disclaimer: everything below is just what worked on my own profile. It's best effort, not official, and not guaranteed. Your data may be laid out differently or partly overwritten, so always work on a copy.

How the recovery works

A suspended tab keeps its real URL encoded inside the park page address, like:
chrome-extension://<id>/park.html?...&url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3D...&title=...

That url= parameter is the original page. Even after the tabs go blank, that park address is still stored in a few places inside your Brave/Chrome profile:

• Saved Tab Groups: <profile>/Sync Data/LevelDB
• Extension storage: <profile>/Local Extension Settings/<extension-id>
• Session snapshots: <profile>/Sessions/Tabs_*

So recovery is: read those records, take each park address, and URL-decode the url= param. The one catch is that the .ldb files are Snappy compressed, so plain text search misses them and you need a LevelDB reader. With that, I got my tabs back, split across the groups.

Quick win if you catch it early: any tab still showing the park page (before it flips to newtab) has the real URL right there in its address bar url= param. Grab those before restarting.

If you want it automated, here's a small standalone Python script (no dependencies) that reads the Saved Tab Groups DB and prints each group with its URLs.

Same disclaimer applies, it worked for me but no promises for your setup: https://gist.github.com/oLucasAguilar/8da32f367d377eab4285b5fe7edd7d63

What seems to cause it, and a possible fix direction (for the maintainer)

Reproduces for me with a large session (~11 saved groups, ~140 grouped tabs, plus ~90 live tabs). I only read the 2.0.12 source, so treat this as a lead, not a verdict.

On startup, background.js awaits SessionRestoreDetector.waitForGroupRestore(), then loops over tabs and reloads any park.html tab with no favicon (and discards normal ones). modules/SessionRestoreDetector.js is a polling heuristic that waits about 5s max with a few "good enough, proceed" fallbacks, and its own comment says it exists to "prevent grouped tabs from becoming blank during browser startup."

With a session this big, Chrome restores collapsed groups lazily, slower than that 5s window. The detector seems to proceed too early, the startup loop reloads/discards grouped park tabs that aren't fully restored yet, and they land on newtab. It looks like a race between the extension's startup pass and Chrome's restore, the exact thing the detector tries to prevent, but a timer can't really guarantee it.

A possible direction: gate per tab on readiness instead of on a clock. For example skip tabs that are still loading, discarded, or in a collapsed group, and don't reload a park tab just because its favicon is empty during restore. Happy to help test.

[sergey-drpa]

I have reproduced this issue.