On Windows 10 I have a scenario similar to the following. Imagine a server that accepts a POST to /random, and it will generate an HTML file with the new random number embedded in the JavaScript. The JavaScript will dynamically display the number in the HTML, but it will also use sessionStorage.setItem("random", randomNumberGeneratedFromServer) to save the random number in session storage. This way if the user hits GET to merely reload the page, the JavaScript will see the random number in session storage and continue to show the same number in the HTML. (The page also uses window.history.replaceState(null, null, window.location.href) to allow F5 to reload the page using GET rather than POST.) It works across browsers.
Now let's say we have a "Regenerate" button on the same page that actually sends a POST back to /random. This will result in the same page getting generated, but with a new random number. The new page can also be reloaded, and it will find the new random number in session storage using sessionStorage.getItem("random"), and display it.
The downside is that regenerating the page using POST results in a new point in navigation history. If you hit the "Back" button, it will show the previous page. Unfortunately the previous page in navigation (which in reality is the same page with the same JavaScript) won't show the previous random number, because when used with GET the JavaScript looks for the random number in the session storage. Since the session storage variable was replaced upon regeneration, both the current page and the previous page will find the same number in session storage. The old random number is gone for good. Both the current page and the previous page will now show the new random number.
At least that's the expectation, and that's what happens in Chrome 116.0.5845.141. But in Firefox 117.0, when I hit the "Back" button to go to the previous page, it shows the old random number! I can even refresh the previous page, and it will show the old random number. And I can navigate forward and it will show the new random number!
Since both pages are identical and when called with GET they load the generated random number from session storage, I can only infer that Firefox is storing different session values with different points in navigation history! This makes no sense, as I had understood session storage to be independent of navigation history.
Is this documented behavior of Firefox to somehow store session storage snapshots associated with navigation history?
After further experimentation, it appears that Firefox is not actually saving a history of session storage associated with navigation history. What appears to be happening in Firefox is that it displaying the cached version of the previous page—the result of the POST, and running its JavaScript. Since the POST version contains the old random number embedded in the JavaScript, this results in the page re-saving the old random number back in the session state.
The moment I actually reload one of the pages in history in Firefox (using GET), this "locks in" the old value so that when I cycle back to the page it loads whatever is in the session storage instead of replacing it (as the cached JavaScript from the POST version did).
Chrome, on the other hand, does not seem to be using the old page from the cache, but instead actually issuing a new GET, which results in the old page retrieving the new random number from session storage as expected.
Firefox thus isn't keeping a history of session storage (whew!), but in essence recreating session storage history in sort of an accidental "event sourcing" because it is running the JavaScript on a cached version of the page.