Serve suspended.html from a website instead of loading it from the extension, to avoid Chrome closing it on upgrade?

[fwextensions]

You've probably already thought of this, but in case not, I'll throw it out there: rather than load suspended.html from the installed extension files, what if it was loaded from an actual webserver, say https://tgs.io, or something? That way, when the extension is updated, those suspended pages wouldn't be considered part of the extension, so Chrome wouldn't automatically close them. That would avoid all the trouble with the update process, so the extension could be updated more often. And if a user uninstalled the extension, the pages wouldn't be closed, so they could change their mind and reinstall.

Rather than include the original URL and title as parameters, they could be stored in the fragment. That way, they wouldn't be sent to the server, and wouldn't be subject to URL length limits. Realized that's how they're already being handled.

Offline support would be necessary, but could be added by making the page a PWA (in theory; I've never tried it). The extension can already inject code into any page, so the suspended page would be able to interact with the extension.

Drawbacks include having to maintain a domain forever (though just hosting it as a page on GitHub might also suffice), and it would probably be a fair amount of work. But it seems like there'd be a significant upside.

[fwextensions]

Another advantage that occurred to me: the web-served page could detect that TGS was no longer installed and then offer to redirect itself to the original URL. Or when its tab is focused, it could just redirect automatically if it can't communicate with the TGS background page, on the assumption the extension has been uninstalled.

[deanoemcke]

@fwextensions It's definitely something I've considered before. I'm trying to find an old issue where I've commented on this before, but I can't seem to find it.

From memory, my main objection to this was the impact it would have on chrome restart. It is actually one of the things I enjoy most about the extension is how quickly it restarts when all the tabs can be loaded locally.

That said, the upside is significant. I'll do some investigation to get a feel for what this might look like.
As mentioned in your other related issue, it won't be in this next release though :P

I'll also try to track down that other issue to see if there was another objection I had that I can't remember right now.

Edit: I found it :)
#271

So in addition to the concerns raised above there are the following considerations:

• If the user is offline when they restart the browser, it will break the extension (you mention a workaround for this above)
• I mention a performance cost to hosting externally. Although I'm not sure this is correct? Other than the initial suspension, it probably wouldn't consume any more resources than a local page. I guess I'd need to test it.
• And I guess it's worth mentioning, it would involve a pretty major refactor. There's a lot of direct communication with suspended tabs via messaging that would have to be refactored. Probably into the content script. Which may increase the bloat of the extension.

[deanoemcke]

For the record, here's somebody who seems to be using TGS as a way to restart chrome quickly: #700

[fwextensions]

It seemed unlikely that you hadn't considered this approach, but the upside appeared worth double-checking.

Totally agree with the desire to keep restarts fast. But my understanding is that for awhile now, Chrome has been reloading only the visible tabs on a restart, leaving the others in the discarded state, so they only load when you activate them. If that's true, restarting with suspended tabs pointing at a remote host might not be any slower.

No idea about resource usage in a cached remote page vs. a local extension page, but I'd assume the process (and therefore, the memory footprint) used to host and render both would be the same.

No doubt the refactoring is an obstacle. But based on a comment somewhere here, it sounded like there was already a solution to the upgrade cycle that would take two cycles to kick in? (In other words, after the next+1 release, subsequent releases wouldn't cause the tabs to be lost? In that case, remote hosting wouldn't be necessary.)

[fwextensions]

To be clear, that was based on this comment:

well the good news is that there was an obvious way to solve this the whole time, but it is going to take 2 new releases before it takes effect (ie. it only kicks in once you have the next new version already installed, and are about to receive the subsequent new version).