Bug 14709 - document.write in onload fails
Summary: document.write in onload fails
Status: RESOLVED DUPLICATE of bug 8961
Alias: None
Product: WebKit
Classification: Unclassified
Component: DOM (show other bugs)
Version: 523.x (Safari 3)
Hardware: Mac OS X 10.4
: P2 Normal
Assignee: Nobody
URL: http://dscoder.com/documentwritetestc...
Keywords:
: 14821 (view as bug list)
Depends on:
Blocks:
 
Reported: 2007-07-22 01:43 PDT by David Smith
Modified: 2007-09-26 21:27 PDT (History)
5 users (show)

See Also:


Attachments
close the write content when the doc is closed (1.46 KB, patch)
2007-08-02 11:24 PDT, Sornalatha Rathnasamy
mrowe: review-
Details | Formatted Diff | Diff
close the stream after write by appending </html> for the corresponding <html> tag added in write() (2.90 KB, patch)
2007-08-14 11:57 PDT, Sornalatha Rathnasamy
sam: review-
Details | Formatted Diff | Diff
test case (413 bytes, text/html)
2007-08-14 13:29 PDT, Sornalatha Rathnasamy
mrowe: review-
Details

Note You need to log in before you can comment on or make changes to this bug.
Description David Smith 2007-07-22 01:43:00 PDT
The linked url shows "success" on the page in firefox, but is blank in webkit. It uses document.write in onload on the <body>. In addition, having the document.write in onload will also cause a subsequent document.write to fail. For example <body onload="document.write('success')"><script type="text/javascript">document.write('success');</script></body> will print nothing, but if the onload on the body is removed, it will print success.
Comment 1 Adam Roben (:aroben) 2007-07-22 01:46:21 PDT
The second example you describe shows a document.write happening *previous* to the one in the onload handler. The body of the <script> element will be executed as soon as it is parsed, which will happen before the onload event fires.

My guess is that the document.write inside the <script> executes correctly, but then the document is cleared when the document.write in the onload handler does an implicit document.open. But this is just speculation.
Comment 2 Sornalatha Rathnasamy 2007-08-02 11:24:28 PDT
Created attachment 15809 [details]
close the write content when the doc is closed
Comment 3 Sornalatha Rathnasamy 2007-08-02 11:25:15 PDT
(In reply to comment #2)
> Created an attachment (id=15809) [edit]
> close the write content when the doc is closed

http://bugs.webkit.org/show_bug.cgi?id=14821 is a duplicate of this bug.
Comment 4 Darin Adler 2007-08-02 18:48:53 PDT
*** Bug 14821 has been marked as a duplicate of this bug. ***
Comment 5 Darin Adler 2007-08-02 18:49:29 PDT
Comment on attachment 15809 [details]
close the write content when the doc is closed

This patch is not for TOT. Must be for the S60 branch.
Comment 6 Mark Rowe (bdash) 2007-08-03 01:46:25 PDT
Comment on attachment 15809 [details]
close the write content when the doc is closed

I'm going to mark this r- as the patch is for the S60 branch while the bug was reported against trunk.  This means that the patch does not address the bug that was reported.
Comment 7 Sornalatha Rathnasamy 2007-08-03 05:51:43 PDT
Comment on attachment 15809 [details]
close the write content when the doc is closed

this patch is applicable to tiger branch as well not just S60. Could someone please review ?
Comment 8 Sornalatha Rathnasamy 2007-08-03 05:51:49 PDT
Comment on attachment 15809 [details]
close the write content when the doc is closed

this patch is applicable to tiger branch as well not just S60. Could someone please review ?
Comment 9 Mark Rowe (bdash) 2007-08-06 02:38:20 PDT
Comment on attachment 15809 [details]
close the write content when the doc is closed

As mentioned, the bug is reported against trunk so a patch for the Tiger branch does not resolve the bug.
Comment 10 Alexey Proskuryakov 2007-08-06 04:23:46 PDT
Also, the patch for TOT should include a test case and a ChangeLog entry. Please see <http://webkit.org/coding/contributing.html> for information on contributing code.
Comment 11 Sornalatha Rathnasamy 2007-08-14 11:57:39 PDT
Created attachment 15964 [details]
close the stream after write by appending </html> for the corresponding <html> tag added in write()
Comment 12 Alexey Proskuryakov 2007-08-14 13:22:51 PDT
The patch still doesn't have a test, so it cannot be landed. However, I'm leaving the review flag on for someone to review code changes.

BTW, this seems to be a duplicate of bug 8961.
Comment 13 Sornalatha Rathnasamy 2007-08-14 13:29:23 PDT
Created attachment 15968 [details]
test case

test case
Comment 14 Mark Rowe (bdash) 2007-08-17 23:26:06 PDT
Comment on attachment 15968 [details]
test case

Your test case should be included in the patch, along with the expected results.  It seems that this test should also be a text-only test rather than dumping the rendertree.
Comment 15 Mark Rowe (bdash) 2007-08-17 23:36:16 PDT
Comment on attachment 15964 [details]
close the stream after write by appending </html> for the corresponding <html> tag added in write()

Your ChangeLog entries should include information about the change as well as a reference to the bug is being fixed, as well as your name rather than "webcore" in the header line.

The name "m_beginWriteStream" seems less than ideal.  It reads more like a function name due to it starting with a verb.  I can't suggest a better name as I'm not entirely clear on what the purpose of the variable is.
Comment 16 Sam Weinig 2007-08-19 17:38:25 PDT
Comment on attachment 15964 [details]
close the stream after write by appending </html> for the corresponding <html> tag added in write()

As noted above, this needs a more detailed ChangeLog and an included test case.  r-
Comment 17 Maciej Stachowiak 2007-08-19 21:43:03 PDT
I'm not sure the basic approach here is right:

a) Writing a </html> close tag shouldn't be necessary to have the written contents actually appear; the fact that it is likely indicates some deeper problem.

b) This probably means that certain kinds of document.write *after* onload won't work right either, and there isn't code around to write the </html> in such cases.
Comment 18 Alexey Proskuryakov 2007-09-26 21:27:46 PDT
This bug doesn't seem active anymore; actually closing as a duplicate.

*** This bug has been marked as a duplicate of 8961 ***