WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED WONTFIX
57906
Reload after document.write in new window loads wrong page
https://bugs.webkit.org/show_bug.cgi?id=57906
Summary
Reload after document.write in new window loads wrong page
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.
Top of Page
Format For Printing
XML
Clone This Bug