In #3885 we noticed that, back then, document.open() had the strange behavior that it updated document's URL to the entry document's URL, but it did not update the corresponding session history entry (SHE). This meant that there could be situations where the document's URL is not equal to its corresponding SHE's URL, which is very strange and led to some bad behaviors detailed in that issue.

/cc @rniwa @TimothyGu @smaug---- who were involved at the time.

We changed the spec in #3946. At the time we believed Safari matched the updated spec, and Firefox and Chromium were happy to follow the updated spec.

Chromium only recently implemented this (/cc @natechapin). @csreis found that this causes a problem, however, in crbug.com/1189026:

1. Visit a page with an iframe
2. frames[0].document.write("foo") will update that iframe's URL to the outer page
3. Navigate the tab (outer frame) to a new URL
4. Go back.

The result is that you load the outer page, with itself in an iframe. In Chromium this is particularly bad because our recursive iframe prevention doesn't work on history traversals, and also somehow our bfcache doesn't kick in. You can thus set up scenarios where for every history traversal that visits the entry, you get yet another nested iframe.

Note that Firefox and Safari do not seem to implement this part of the spec; they restore the original URL, not the URL that was set by document.open() updating the document's URL/SHE's URL. So this means our testing of Safari back in 2018 was incomplete.

This seems like an unintended, but somewhat predictable, consequence of our efforts to align document's URL with SHE's URL. Ultimately if you set an iframe's SHE's URL to the entry document's URL, you are setting yourself up for recursion upon history traversal (or session restore, e.g. closing and reopening the tab).

So, we have a few choices on where to go from here:

• Accept this problem as the cost of keeping SHE's URL and document's URL in sync. We're not yet sure if this is feasible in Chromium; in particular, the change hasn't hit stable yet, and once it does, we might be forced to mitigate (somehow) if these recursive frames break enough sites.

• Accept this problem as the cost of keeping SHE's URL and document's URL in sync, but beef up recursive frame detection in Chromium. (And possibly in other browsers, if they have similar limitations.) It's not clear this would be much better; in particular recursive frame detection just refuses to load the iframe, which might be just as breaking to sites.

• Revert back to a world where SHE's URL is not always equal to the corresponding document's URL. Maybe try to solve some of the issues identified in document.open() can make a document's URL go out of sync with its history entry #3885 in another way.