Bug 23813 - window.open followed by document.write results in unsavable pages
Summary: window.open followed by document.write results in unsavable pages
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit Misc. (show other bugs)
Version: 528+ (Nightly build)
Hardware: Macintosh OS X 10.5
: P2 Minor
Assignee: Nobody
URL: http://james.wheare.org/stuff/bugs/sa...
Keywords: HasReduction, InRadar
Depends on:
Blocks:
 
Reported: 2009-02-06 20:00 PST by James Wheare
Modified: 2009-02-07 14:23 PST (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description James Wheare 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>");
}
Comment 1 Mark Rowe (bdash) 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?
Comment 2 James Wheare 2009-02-06 20:27:41 PST
Yup that's correct. Additionally, the View Source option remains greyed out.
Comment 3 Mark Rowe (bdash) 2009-02-06 20:33:10 PST
Thanks for the info.
Comment 4 Mark Rowe (bdash) 2009-02-06 20:33:22 PST
<rdar://problem/6565915>
Comment 5 Alexey Proskuryakov 2009-02-07 03:58:09 PST
See also: bug 3524.
Comment 6 Alexey Proskuryakov 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.
Comment 7 James Wheare 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).
Comment 8 Alexey Proskuryakov 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>
---------------

Comment 9 James Wheare 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.
Comment 10 James Wheare 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.
Comment 11 Alexey Proskuryakov 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!