|Summary:||Reload after document.write in new window loads wrong page|
|Product:||WebKit||Reporter:||Charles Reis <creis>|
|Severity:||Normal||CC:||abarth, ap, creis, darin, fishd, mihaip|
|Version:||528+ (Nightly build)|
|OS:||OS X 10.5|
|Bug Depends on:||50331|
Description Charles Reis 2011-04-05 17:02:21 PDT
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.
Comment 1 Alexey Proskuryakov 2011-04-05 21:06:13 PDT
At the moment, there is no test case attached.
Comment 2 Charles Reis 2011-04-06 09:07:08 PDT
Created attachment 88439 [details] Layout test for window.open, document.write, location.reload
Comment 3 Charles Reis 2011-04-06 12:10:10 PDT
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...
Comment 4 Charles Reis 2011-04-06 13:27:46 PDT
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.
Comment 5 Alexey Proskuryakov 2011-04-06 14:32:34 PDT
Is there a regression test for this? Also, a comment would be better than code that just looks intentional :)
Comment 6 Adam Barth 2011-04-06 15:01:50 PDT
> 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.
Comment 7 Darin Adler 2011-04-06 16:39:58 PDT
Did this come up on a real world website?