Cached Content Updating and State Saving

Continuing the discussion from Disabling automatic scroll restoration on navigation:

As a user, I want better platform-wide base support for things like caching page content/state and saving/restoring form state across history traversal (and whether restoring state should happen before or after the scripts on the page first synchronously run, to allow JS to calculate defaults without having to care if this has happened).

For example, right now on GitHub, if I visit an issue’s thread and stay on the page until a new comment comes in, that new comment is added to the thread in real-time. However, if I navigate away from the page and use Back to return to it, those comments disappear.

This could maybe be solved with an application-specific use of the state object with replaceState, but it would make just as much sense to have a mechanism by which a page can say “the current DOM content is the new cached version of the page, use it to replace the content currently in the cache”. (Even with Service Workers, this kind of cache-replacement is non-trivial: I guess you could override the cache, do “document.html.outerHTML” and then make some kind of secret-handshake Fetch to inform the service to use it, but now you’ve killed UA caching, especially UA cache eviction, just to implement a trivially different version.)

As an example of the interaction of form behavior with history, when I navigate away from a page where I’m filling something out (specifically, the “New issue” page, or the comment field on an existing issue), the form will be re-filled with what I had been typing… sometimes. I’m not sure if this is a UA feature or a GitHub feature, but it seems to differ between the New Issue page and the Add Comment form, and between.

This is another thing that could be solved with some mechanism to snapshot page state in history at a page-content level: it could also be given special treatment, where a page may request a behavior like “save the page content, but don’t save the form content”, or “save the form content, but not the page elements” (to prevent ephemeral things like dynamically-generated tooltips from being pegged as page content).

Declarativity and Default Behavior

lt would be nice if the default behaviors of the UA were made helpful-by-default for users (including mechanisms like declarative properties to control this behavior) and authors (developers), rather than requiring pages to opt-in to recovering form state (or, worse, right a hacky implementation to do it themselves).

Of course, there are potential issues in situations where a user on a shared computer navigates away from a page and expects sensitive form content to be cleared - however, this is already a problem to some extent, and the way the Web ecosystem is gravitating toward solving it is, rightly, to add browser-level feature support for shared computing, like incognito/private browsing, kiosk mode, and associating session / history to user accounts. Pages may opt to tighten their history if necessary for their specific case, but forcing this level of paranoia on all pages is not called for (the benefits of it working as intended outweigh the risks of it being exploited).

I agree that web apps need more control over browser state restoration timing. However I don’t think having the ability to change restoration timing to before or after sync JS is flexible enough. For example consider cases when calculating the new values to restore requires async operations (e.g., fetching new content from net). IMHO a more flexible and powerful approach is to give applications the ability to disable automatic restoration and also the ability to trigger it at a time of their choosing.

Perhaps the solution is to make it easier to do something like that using ServiceWorker. I don’t think adding a third mechanisms beside replaceState and Service worker just to achieve caching of DOM is justified. Also, why is it needed to cache the DOM rather than the data behind it which is what most single page applications are doing.

It can be but why is it not fixed with existing form restoration feature? I am curious as what is the fundamental issue? I can imagine restoration timing issue detailed above may be the cause but that can be fixed without introducing a heavy feature like page snapshot.

As you have pointed out the exact thing that needs to be cached is very application (or even page) specific. I am not yet convinced that APIs to snapshot the page (DOM?) are necessary or useful here.