Feature suggestion: lazy loading of suspended tabs (at chrome startup)

[tonsimple]

I did a github search (but am not sure it has not been suggested because it is like, really obvious)

Basically, the idea is to have Great Suspender exhibit Sloth-like behavior (https://chrome.google.com/webstore/detail/sloth/filkeckmpdjogddcamkafnekhgfaehkc?hl=en-US&gl=IN) on startup (that is to say, discard most suspended tabs during startup), so that it does not have to even load the "tab is suspended" screen until tab gains focus.

Dunno if it is possible tho

EDIT: I have performed some experiments on suspended tabs using chrome://discards and suspended tabs can definitely be discarded and urgent-discarded

I have not yet found any apparent negative consequences from such "manual discarding"

If it doesn't mess anything up in terms of say, session management (more careful testing than I can really do is probably needed), it would definitely be neat if Great Suspender, during startup, instead of loading all the hundreds of "tab suspended" screens would just discard everything that is not focused

[deanoemcke]

I have already experimented with this, and discarding before a suspended tab fully loads can lead to the favicons and tab titles not loading properly. See this issue: https://github.com/deanoemcke/thegreatsuspender/issues/719

However, the latest dev version (soon to be released on the chrome webstore) does have a new feature that allows suspended tabs to discard after they have loaded.

This does not help you if you are hoping to speed up chrome load times. But it does significantly reduce the memory usage of the extension once all the suspended tabs have finished loading and then discarding.

[tonsimple]

Ah, I see. My biggest issue currently is that extension often crashes or hangs forever during startup of large sessions.

However, that is a separate issue that I started, and I have a workaround.

By the way, using that workaround I use for Chrome startup of large session does cause similar favicon issues - favicons often "go AWOL"

But in "chrome flag workaround" induced case, favicon is reset to normal when the suspended tab is selected, so "good enough for me"

[CollinChaffin]

@tonsimple you perhaps should catch up on reading open issues since everything you've mentioned in this issue you opened has been opened and/or already implemented for some time particularly the "AWOL" favicons there are actually multiple issues open on it.

However, as for large session restores, what are you using to save and restore these large sessions, another extension or TGS? If it is another extension I speak from experience it it 100% dependent on the state all your tabs are in AT THE TIME OF SESSION SAVE. Because, a saved session with 300+ tabs (a minimal norm for me) even on an older laptop are re-opened upon a manual session restore using a 3rd party ext I use in a matter of maybe 10 seconds with the same little overhead as when I closed Chrome - BECAUSE THEY WERE MOSTLY/ALL SUSPENDED. If you're restoring suspended tabs, the URL is a local/internal chrome:// url for TGS, so it is impossible they are consuming much of anything, since nothing has actually loaded until you click on each.

Now, on the other hand if you're saving the state of your 300+ tab session with NO SUSPENDED TABS and all live URL indicators to the internet......that too has NOTHING to do with TGS (why would it if they aren't suspended via TGS?), instead that action relies solely on Chrome's abilities and there are actually non-default flags you should look into to make that less painful although I not only cannot imagine doing that to my system at every restart, but I speak from experience it does NOT take all that many open Github tabs restoring ACTIVE all at the same time before GH will begin issuing a quick rate-limit ban of your address, and if you keep doing it you can risk similar and even more serious permanent action from them or any other site that has sensitive DDOS measures in place and doesn't like being hammered.

I do worry when I see someone posting that a specific extension "crashes or hangs forever" without providing any detail of crash messages, screenshots, etc.....I've been a power TGS user for years and I don't think I've ever once seen Chrome report TGS specifically being hung or "crashing". Not that I don't believe you but what makes you believe it's TGS "hanging" and also what exactly is reported to you at the "hang" or "crash"?

[tonsimple]

@CollinChaffin

Session save/restore is being done by TGS, and the tabs in the affected session are all suspended (ensured by using the "resuspend" feature from TGS's session management, waiting for proper opening of everything, shutting down chrome, rebooting the machine for good measure, then trying to start Chrome again)

The URLs of resulting tabs, upon restore, is TGS's extension URL.

As for screen shot... well, I could screenshot the "extension has crashed" message chrome gives, but that would not be very informative. If TGS puts a crash log somewhere when it crashes, I could reproduce the behavior and grab the logs....

[deanoemcke]

@tonsimple i have discovered over the past week so new chrome behaviour that must have been implemented in a recent release. this is the cause of all the recent favicon issues that have been observed. given this new knowledge, i've largely rewritten the startup behaviour of the extension. hopefully this will address your crashing issues on session restore. as a side note: this new chrome behaviour seems affect opening up a window with a lot of tabs. it seems that now chrome does NOT load all of the tabs, resulting in much better performance. you might find that reloading a session as unsuspended will actually work a lot better for you (assuming you have the latest v70 of chrome).

Let me know how this works out for you. And if you are on a development version of TGS, then try updating to the latest version (v7.0.136)

[deanoemcke]

Related issue for performance issues when opening a window full of suspended tabs: #793