4 ms·
I actually want this to happen in all of my tabs because I want them to UPDATE. This is why I keep them open in the first place.
by iopq 10y ago
I actually want this to happen in all of my tabs because I want them to UPDATE. This is why I keep them open in the first place.
- zeveb 10y agoI think that the mechanism I suggested elsewhere would handle this best: each tab's complete state (DOM, JavaScript &c.) should be marshalled to disk at quit (and checkpointed periodically, in case of crashes); on startup, all tabs are loaded and their DOM & JavaScript contexts restored. If a tab's context had it set to update periodically, then that periodic-update context would be restored; if not, then the remote server would never be contacted until and unless the user hits reload. This seems so obviously correct to me that I wonder what I'm missing.
- kuschku 10y ago> This seems so obviously correct to me that I wonder what I'm missing. You are missing that > should be marshalled to disk at quit is not easily doable.
- zeveb 10y agoWhy not? The DOM is, ultimately, just HTML. The VM state is just data in RAM, which should be eminently serialisable. I'd think it's the sort of thing which ought to be child's play.
- kuschku 10y agoThe VM state isn't that easy when you remember that JS can keep open sockets to other things, can launch processes, etc. Sure, you could find a way to serialize it, but that'd be a lot harder — you can't hust go back to halfway the middle of receiving something through a socket.
- zeveb 10y agoOne could just close open connexions — after all, a network connexion can always die anyway. I really hope that JavaScript in a browser can't launch processes!