NEW 23813
window.open followed by document.write results in unsavable pages 
https://bugs.webkit.org/show_bug.cgi?id=23813
Summary window.open followed by document.write results in unsavable pages
James Wheare
Reported 2009-02-06 20:00:59 PST
If a window opened with javascript window.open has all its contents overwritten with document.write() by the opening script, the page contents can't be saved, and the View Source option is greyed out and disabled. The save dialog's "Export As:" field defaults to "DownloadedFile.html" and on confirm, the following error alert is shown: The document "DownloadedFile" could not be exported as "DownloadedFile.html". This bug does NOT affect windows opened with an empty URL (about:blank). These windows are successfully saved as "unknown.webarchive" by default and the View Source option is not greyed out. --- This technique is employed by some banks to provide popups for printing and saving. This issue previously affected Version 3.0.4 (5523.10.6) with the additional issues of not being able to view the DOM in the web inspector, or print the rendered page. These issues have been resolved as of the latest nightly --- Test cases at URL --- Source: function doPopup(url) { var win = window.open(url); win.document.write("<html><body><h1>This is overwritten content</h1></body></html>"); }
Attachments
Add attachment proposed patch, testcase, etc.
Mark Rowe (bdash)
Comment 1 2009-02-06 20:22:22 PST
To clarify, the issues of being able to view the DOM or print the page have been resolved in the nightly build, but the page still cannot be saved?
James Wheare
Comment 2 2009-02-06 20:27:41 PST
Yup that's correct. Additionally, the View Source option remains greyed out.
Mark Rowe (bdash)
Comment 3 2009-02-06 20:33:10 PST
Thanks for the info.
Mark Rowe (bdash)
Comment 4 2009-02-06 20:33:22 PST
<rdar://problem/6565915>
Alexey Proskuryakov
Comment 5 2009-02-07 03:58:09 PST
See also: bug 3524.
Alexey Proskuryakov
Comment 6 2009-02-07 04:04:16 PST
The bug description mentions actual behavior, but it not the expected behavior. Note that in Safari, View Source and Save work with original source as retrieved from the network, not with a serialization of the current frame content. So, it seems that the current behavior is (mostly?) correct - there is hardly any reason to save the original source if it has been completely overwritten already.
James Wheare
Comment 7 2009-02-07 05:59:49 PST
And yet those options DO work if your original document has no URL. This behaviour may be correct but it's certainly not desired. I have seen banks using this technique to display saveable content. This content can be saved in other browsers (tested with Firefox).
Alexey Proskuryakov
Comment 8 2009-02-07 13:44:28 PST
So, am I right that the desired behavior in this bug is just "do what Firefox does", nothing more concrete? There are lots of problems I've seen with Firefox behavior, as pages saved from serialized content are often broken. E.g., try opening the below document in Firefox, saving it, and opening the result again: --------------- <script> document.write("<p>a</p>"); </script> ---------------
James Wheare
Comment 9 2009-02-07 13:54:38 PST
The desired behaviour is to be able to save the document, as either a .webarchive or .html file. This appears to be possible in situations where there is no existing DOM, but disabled when the DOM has been overwritten with document.write. I understand that a modified DOM probably leads to complications, but the current behaviour still remains unexpected and undesired. I was using Firefox as an example, not as a suggestion that you should just copy their exact implementation. I meant no disrespect.
James Wheare
Comment 10 2009-02-07 13:58:48 PST
Also, while the example you cite is indeed a problem, the specific test case I provided wouldn't suffer from this issue as the document.write only exists in the originating document, so wouldn't be saved along with the page's contents.
Alexey Proskuryakov
Comment 11 2009-02-07 14:23:20 PST
Yes, remembering that the document didn't modify itself is an interesting idea - not sure if that will always result in consistent behavior, but it's certainly something to consider. Thanks!
Note You need to log in before you can comment on or make changes to this bug.