So did
some Chrome developers back in 2015. From
https://developers.google.com/web/updates/2015/09/tab-discar...:
> Future improvements: the tab serializer
> The tab serializer is a future piece of work we think may lead to significant improvements on our current approach to tab discarding. It takes the contents of a Chrome tab and serializes its current state into a binary blob. This binary blob can later be deserialized into a tab.
> The serializer would serialize almost everything Chrome, Blink and V8 need to properly preserve a tab (something Chrome extensions tackling this problem historically haven't been able to easily achieve). Serialization would include the usual suspects: the DOM (with a lot of WebGL and Canvas included), CSS and the state of the V8 JavaScript VM.
> If you use Android or ChromeOS, you may know that (similar to the tab discarding experiment covered in this post) we kill background tabs aggressively in order to ensure memory usage is low. The issue with the way we tackle this was that your tab would lose all of its state.
> When you showed interest in the tab again, we would have to reload it and all your interaction with it would be lost. The tab serializer just approaches this problem in a way that gets you back to almost exactly what you were without requiring going back to the network.
> We look forward to sharing more information about this work at a later date.
6 years later, we have... wait for iiiiiit... something called "freeze-dried tabs": https://www.xda-developers.com/google-chrome-89-freeze-dried...
It basically presents a pseudo-image of the current tab while the actual tab is loading in the background. The pseudo-picture contains text and image drawing commands so it can be zoomed in and out, and it's a snapshot of the entire webpage (probably subject to limitations I'm yet to identify). It's not interactive though beyond having a concept of "hit targets" for anchor elements, and AFAIK Android's only using it to speed up perceived browser startup at the moment (so not for tab switching).
To me, the fact that this silly feature has shipped on Android ("THE" platform), and for the most part very imperfectly filled the vacuum that would have been a canonically perfect match for tab serialization, is fairly concrete signal that tab serialization will never be implemented. D:
I can admittedly sorta appreciate that WebGL and DRM state would probably be tricky to perfectly save - the text says "a lot of", suggesting that the feature would sometimes fail and produce an inconsistent experience. Hmph. That would be better than nothing. And it's not like Google couldn't go look at how Firefox does it for ideas....
Sometimes I just wish a bunch of rich millionaires with no idea what to do with their money would make a giant big deal about _paying Google_ to implement specific obscure features into Chrome - like this one :D. It would cause all sorts of hilarious chaos in terms of processing the payment, which would itself make for excessively amusing headlines about feature prioritization and such.