Repro steps: w = window.open(any_url) w.document.write(1) w.location.reload() The reload() results in the *opener's* url being loaded into the child window, instead of any_url. Layout test attached. Note that in debug builds, it also hits the ASSERT in HistoryController::restoreScrollPositionAndViewState, which is being discussed in bug 50331.
At the moment, there is no test case attached.
Created attachment 88439 [details] Layout test for window.open, document.write, location.reload
I've tracked it down to Document::write, which calls Document::open using the ownerDocument it got from V8HTMLDocument::writeCallback. In this case, ownerDocument is the opener document, rather than the new window's document. All of that code seems pretty intentional, though. Is this intended behavior? I found it pretty surprising to have the opener's page show up in the new window...
Adam Barth points out that this is actually intentional. The opener page is overwriting the child page with document.write, so its security context takes over. WebKit's behavior still differs from Firefox and IE (which simply reload the "1" from the document.write), but at least Firefox replaces the URL of the new window with the opener's URL. I'll mark it won't fix.
Is there a regression test for this? Also, a comment would be better than code that just looks intentional :)
> Is there a regression test for this? Yes. The test was added when I added this code. > Also, a comment would be better than code that just looks intentional :) Comments are good. There isn't a test for the root issue Charlie is investigating because the underlying problem is that the embedder isn't properly handling messages its getting from WebKit.
Did this come up on a real world website?
(In reply to comment #7) > Did this come up on a real world website? No, it's from a toy example page showing incorrect URL bar behavior in Chrome (not Safari). As Adam mentions, it's likely an issue in the embedder logic.