Bug 57906 - Reload after document.write in new window loads wrong page
Summary: Reload after document.write in new window loads wrong page
Status: RESOLVED WONTFIX
Alias: None
Product: WebKit
Classification: Unclassified
Component: History (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC OS X 10.5
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on: 50331
Blocks:
  Show dependency treegraph
 
Reported: 2011-04-05 17:02 PDT by Charles Reis
Modified: 2011-04-06 17:21 PDT (History)
6 users (show)

See Also:


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

Note You need to log in before you can comment on or make changes to this bug.
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?
Comment 8 Charles Reis 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.