Bug 57906

Summary: Reload after document.write in new window loads wrong page
Product: WebKit Reporter: Charles Reis <creis>
Component: HistoryAssignee: Nobody <webkit-unassigned>
Status: RESOLVED WONTFIX    
Severity: Normal CC: abarth, ap, creis, darin, fishd, mihaip
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: PC   
OS: OS X 10.5   
Bug Depends on: 50331    
Bug Blocks:    
Attachments:
Description Flags
Layout test for window.open, document.write, location.reload none

Charles Reis
Reported 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.
Attachments
Layout test for window.open, document.write, location.reload (1.77 KB, application/zip)
2011-04-06 09:07 PDT, Charles Reis 		no flags
Details
View All Add attachment proposed patch, testcase, etc.
Alexey Proskuryakov
Comment 1 2011-04-05 21:06:13 PDT
At the moment, there is no test case attached.
Charles Reis
Comment 2 2011-04-06 09:07:08 PDT
Created attachment 88439 [details] Layout test for window.open, document.write, location.reload
Charles Reis
Comment 3 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...
Charles Reis
Comment 4 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.
Alexey Proskuryakov
Comment 5 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 :)
Adam Barth
Comment 6 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.
Darin Adler
Comment 7 2011-04-06 16:39:58 PDT
Did this come up on a real world website?
Charles Reis
Comment 8 2011-04-06 17:21:50 PDT
(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.
Note You need to log in before you can comment on or make changes to this bug.