History pushState inside iframe, affecting parent window layout in Chrome?

Question

I have an iframe in which the pushState is triggered in order to provide the user with the ability to browse back and forward. This iframe has some transform applied to it, and the parent window responds to mouse move updating the perspective-origin.

See the page in question.

All is fine in Safari, but when browsing back in history with Chrome, the layout of the parent breaks horribly. This sounds crazy to me, as the iframe contents shouldn't ever influence the layout of the parent window.

To test you can browse a few tabs inside the iframe, then click the back button in the browser. Also note how if you go to "People" tab, and open any of the persons with a picture, the "Back" button in the top left calls the same function bound to pop state (furnax.goBack), without affecting the parent window.

Either this is a bug, or browsing back the history does more than I think.

I hope anyone has some insight.

---

Popstate handler:

$(window).on("popstate", function () {
  if (furnax.popStoryEnabled) furnax.goBack();
});

goBack function:

goBack: function () {
  var myHistory = tempDb.getItem("prev").split(",");
  var to = "";
  if (myHistory != "") {
    to = "#" + document.getElementById(myHistory[myHistory.length - 1]).id;
  } else {
    to = "#" + $(".view").first().attr("id");
  }
  furnax.load(to, "pushright", true);
  myHistory.pop();
  tempDb.setItem("prev", myHistory.toString());
},

Answer 1

This is happening for me in both Chrome 41 and Safari 8 on OS X 10.10.2. I don't think the issue is with pushState. I believe what's happening is that when you change the URL in the iframe, the browser sets focus on the iframe and auto-scrolls the document to show the full iframe.

I believe it's similar to a bug I'm experiencing with focusing on inputs inside a CSS transformed iframe. Webkit bug #143100, Chromium bug #470891.

I'm not sure if your situation qualifies as a bug, as I believe it's intended behavior for browsers to do everything they possibly can to show focused elements, even if that means scrolling an overflow:hidden element. Then again, I'm not positive the iframe is actually receiving focus, it might be a different issue that just has some overlap.

One thing I would try is to make the pop state handler move the "iPhone" to the center of the window, and only change its URL after it has finished animating. If that doesn't work, maybe you can take a look at the example page I reference in my bug reports. It might give you some additional insight into the nature of the automatic scrolling.