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>"); }
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?
Yup that's correct. Additionally, the View Source option remains greyed out.
Thanks for the info.
<rdar://problem/6565915>
See also: bug 3524.
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.
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).
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> ---------------
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.
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.
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!