Able to reproduce the issue on MAC 10.11.4, Windows 10 and Ubuntu 14.04 using chrome stable version #54.0.2840.71 and latest canary #56.0.2896.0

This is a non regression as it is observed from M30 to latest stable & Canary.Hence, marking it as untriaged to get more inputs from dev team.

Please find the attached screencast of M30 & stable Builds.

Deleted: 657317-M30.mp4 560 KB

	657317-M30.mp4 560 KB View Download

Deleted: 657317-Stable.mp4 426 KB

	657317-Stable.mp4 426 KB View Download

Thanks for the report.  This is expected behavior, but fortunately there's a workaround you can use for the behavior you're looking for.

When you go back, Chrome uses session history items to try to load what was showing before into each iframe.  You can observe that the numbers shown in the iframes are the same as they were the last time you visited the page.  For example, in the 657317-M30.mp4 video in comment 1, the sequence of numbers shown when clicking the "Reload" link is:
1, 2, 3, 2, 4, 1, 2, 3, 2, 4
Once the user starts going back, the iframes show those same numbers in reverse order:
4, 2, 3, 2, 1, 4...

In contrast, the number displayed in the main frame is randomly generated by script every time you visit the page.  (We don't persist the entire contents of the document within the history item, so we don't remember what number was there before.)  That explains why the numbers don't match.

As an aside, you're correct that the src URL of the iframe matches the number in the main frame, but that doesn't reflect the URL being loaded from the history item.  (The same is true if you follow a cross-origin link in an iframe-- the parent page can no longer see which URL is loaded in the iframe, and the iframe src URL doesn't match it.)

In Chrome, you can work around this by making the iframe not "match" the history item when you come back.  Chrome matches iframes with history items using the frame's name attribute, and if that isn't specified, it falls back to creation order / location in the frame tree.  (I think Firefox uses the src URL for the matching, which is probably why this behavior doesn't repro there.)  Thus, you can just give the frame a different name every time you visit and the history item won't apply.  Or you can set the name to match the URL.

For example, you can add this line to your script.js file to make the bug go away:
el.name = randomInt;

Hope that helps!

Hey Lukas, thanks for the detailed response - now I have a much better understanding of how this behaviour comes about.

I can also confirm that using different names for the iframe solves the issue on Chrome. Interestingly, it does not solve it on IE.

Nonetheless, I would like to press you on this being 'expected' behaviour. When writing this code, its back-button behaviour seems very surprising to me, and likely to most web devs. Specifically, the iframe is not only sent with a no-store cache header, but it could also point at a wildly different url and will still show this behaviour. Here is what I mean:

Say you reload the page a bunch of times. Then you stop and edit script.js so that it has new behaviour and even loads a totally different URL, like so:
var el = document.createElement("iframe");
el.src = "http://www.google.com/rofl";
console.log("yep, I run but the back button won't listen to me :(")
document.body.appendChild(el);

Even this gets ignored entirely - even though the console.log bit runs immediately, on the first back-button click. So the new code does execute, but shows a different behaviour. I guess what I'm saying is that it feels to me as if the caching/restoring being done by the back button is too aggressive and does not consider the iframe's src attribute nor its http headers - both of which I would have 'expected' it to honor. 

What do you think?

Sorry for the delayed response.

At one level, I think you're mixing up cache behavior vs session history behavior.  No-store headers don't affect whether the browser tries to load a history item into a frame, for example.  The browser is trying to take the user back to where they were at the time, including for subframe URLs.

You're correct that modifications to a page make this a fundamentally impossible goal in general-- you can't always match up where you were last time to which frames are on the page the next time you visit, since the page could have changed arbitrarily in the meantime.  (This may be one of the reasons this behavior hasn't been covered in the spec.)  Browsers are forced to take a best effort approach to try to match up history items to subframes on the page when doing a history navigation, and each approach has some downsides.

Chrome inherited its name-based approach from WebKit.  This approach gives web developers some minimal control over it (by assigning the frame's name), and falls back to frame creation order (which has failure modes like  issue 500260 , where frames sometimes get swapped).  It also doesn't handle cases like this well.

I think Firefox uses the src URL to match history items to frames, which has the nice property that changes to the page won't lead to history items being restored in them.  However, it's almost certainly going to have its own failure cases, likely affecting pages that load the same URL into multiple frames (or appearing to break the back button due to minor changes to the frame's URL).

There's some ongoing discussion on  issue 500260  to try to find the best way forward.  It's worth starring that bug if you want to follow along (though we haven't had time to get back to it recently).  One of the the extra challenges is dealing with backward compatibility if we decide to make a change, since all the existing session data on disk uses the name-based approach rather than the URL-based approach.  Still, it may be possible to make a change at some point.

Hope that clarifies things.

Thanks for clarifying. It's been very helpful to 'solve' the issue by changing the iframe name.

I'll also be sure to follow the other issue for a more general solution.