First up is a simple one: Does setting srcdoc replace the current history entry or add a new one?

Chrome & Firefox: Replace if the current document url is about:srcdoc, otherwise add.
Safari: Always replace.

I'm pretty sure Chrome & Firefox are doing the right thing here and it's somewhat spec'd.

How is a srcdoc entry stored in session history? It's currently unspec'd.

Test:

1. https://iframe-session-history.glitch.me/.
2. Set cookie: give all responses no-store (just to stop bfcache).
3. iframe-1: Set srcdoc to Math.random().
4. iframe-1: Navigate to 'one' via location object.
5. iframe-1: Set srcdoc to Math.random().

This creates history entries [srcdoc1, 'one', srcdoc2] in Chrome/Firefox and [srcdoc1, srcdoc2] in Safari.

Each browser behaves differently when traversing to the srcdoc entries.

Chrome: Recreates the document using the srcdoc of the iframe. As in srcdoc1 and srcdoc2 use the same source, which is different to the source srcdoc1 used when it was first created.

Firefox: Seems to store the srcdoc source along with the history entry, so srcdoc1 and srcdoc2 use different source, which is each the source they were created with.

Safari: Restores the original history entries in these places, as if the srcdoc stuff never happened.

Another test:

1. https://iframe-session-history.glitch.me/.
2. Set cookie: give all responses no-store (just to stop bfcache).
3. iframe-1: Set srcdoc to Math.random().
4. "Navigate to same origin page"
5. back()

Chrome: iframe empty. I guess this is because it looks at the srcdoc of the iframe which is empty, since the page has reloaded.

Firefox: Restores the iframe to its previous content.

Safari: Restores the iframe as if setting srcdoc never happened.

This seems consistent with the findings above. Firefox's model seems to make the most sense to me. Chrome's behaviour is ok I guess. Safari's behaviour is plain weird.