Open Bug 220055 Opened 22 years ago Updated 1 year ago

document generated with document.write() does not create onLoad-Event

Categories

(Core :: DOM: Core & HTML, defect)

Product:
Core
Component:
DOM: Core & HTML
Type:
defect

Tracking

()

People

(Reporter: Peter.Nabbefeld, Unassigned)

References

Details

Attachments

(5 files)

Please try profile/test-moz.html with IE and MOZILLA
2.72 KB, application/x-zip-compressed
Details
Testcase 1
510 bytes, text/html
Details
Testcase 2
497 bytes, text/html
Details
Testcase 3, same as 2 but without external stylesheet written
403 bytes, text/html
Details
Testcase 4, based on remarks of comment 10
516 bytes, text/html
Details
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-AT; rv:1.4) Gecko/20030624 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-AT; rv:1.4) Gecko/20030624 After creating a document with document.write(), only the body is rescanned, and no JavaScript is started. Especially the style sheet (<LINK ...>) is not used, and <BODY onLoad='...'> does not execute. It all works with IE. If You need the source code, please request by email. Reproducible: Always Steps to Reproduce: 1. 2. 3.
---> DOM Level 0 Peter: would it be possible for you to attach a reduced testcase? You can do that via the "Create a New Attachment" link above. That will speed things along; thanks -
Assignee: rogerl → dom_bugs
Component: JavaScript Engine → DOM Level 0
QA Contact: pschwartau → ashishbhatt
First: The stylesheet works - sorry, it's been my error. Sorry. Second: onLoad does not work in Mozilla, but in IE.
I've found out the cause for some of the problems: The status 'local source' seems to get lost after writing to document: The alert boxes do not get displayed because of popup window blocking. But they are displayed when I use my local web server instead of my local file system (after I've copied my files to the document root). However, it is important for testing, that I can also use the file system. The 'problem' with source code remains: In IE, the generated source code is shown, but Mozilla shows the original source code. This might be a philosophic question, but it should be documented as a difference to other browsers (or, perhaps the documentation should be in a place easy to find, if there already is some).
Severity: major → normal
Attachment #132035 - Attachment mime type: application/x-compressed → application/x-zip-compressed
Confirming the onload problem with a Linux build too.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows 2000 → All
Hardware: PC → All
Summary: document generated with document.write() does not use the stylesheet and does not create onLoad-Event → document generated with document.write() does not create onLoad-Event
I've made two testcases which could be interesting for this bug. Both are extactly the same, only the place where the function writedoc() is called is different. In testcase 1, writedoc() is called just after it is defined. In testcase 2, writedoc() is called in the body onload event. writedoc() writes a new document with an external stylesheet. This stylesheet has one css rule: body{background-color:green}. The original document has body style="background-color:red". Results: Testcase 1 - alert('test') is called, but the document's background-color stays red. Testcase 2 - alert('test') is not called, but the document's background-color becomes green. I would expect that alert('test') gets called and that the document's background-color becomes green in both cases. I am using: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a1) Gecko/20040520 Firefox/0.8.0+
Attached file Testcase 1 —
This is the generated source from the generated source bookmarklet: <html> <head> <title>bug 220055 - function writedoc() directly after function writedoc()</title><script> function writedoc() { var hdr = "<link rel='stylesheet' type='text/css' href='data:text/css;charset=utf-8,body%7Bbackground-color%3Agreen%3B%7D'>"; document.open("text/html", "replace"); document.writeln("<html><head>" + hdr + "</head><body onload=\"alert('test');\"></body></html>"); document.close(); } writedoc(); </script><link rel="stylesheet" type="text/css" href="data:text/css;charset=utf-8,body%7Bbackground-color%3Agreen%3B%7D"></head> <body style="background-color: red;" onload="alert('test');"> </body> </html>
Attached file Testcase 2 —
This is the generated source of the generated source bookmarklet (from this testcase): <html> <head><link rel="stylesheet" type="text/css" href="data:text/css;charset=utf-8,body%7Bbackground-color%3Agreen%3B%7D"></head><body onload="alert('test');"></body> </html>
> and that the document's background-color becomes green in both cases. This expectation is incorrect, since in testcase 1 the original <body> node is never removed from the document (document.open() on an already-open document is a no-op, so you're trying to create a document with two <body> tags and our parser does whatever fixup we do on such invalid documents; the resulting document has an inline style rule on the <body> that sets the color to red, overriding the stylesheet). If you used a !important rule in the sheet, the background color would change, correctly. That all said, the basic problem is that document.write documents don't really hook into the docloader and such jazz properly, as far as I can tell.
Yes, sorry. This was a misconception from my side, because of missing knowledge. Another testcase. The difference with testcase 2 is that there is no external stylesheet written with document.write. This time the onload event is fired from the written body tag.
Interesting.... So the problem is that calling document.close() before the document is finished loading (that is, while the stylesheet is still loading) prevents onload from firing? What happens if you call document.close off a timeout (say 5 seconds to give the sheet time to load)?
No, that doesn't help. The alert is not fired. With something like this, on the other hand, the alert is fired: <body onload="setTimeout('writedoc()',0)"
Assignee: general → nobody
QA Contact: ashshbhatt → general
https://bugzilla.mozilla.org/show_bug.cgi?id=1472046 Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5. If you have questions, please contact :mdaly.
Priority: -- → P5
Severity: normal → S3
Blocks: 1885937
See Also: → 1663633

Link to jira: https://mozilla-hub.atlassian.net/browse/FFXP-1821
Also adding tentative scheduled info to the user story.

URL: https://mozilla-hub.atlassian.net/bro...
Priority: P5 → --

I'm unsure if there still is a problem here.

For me, the testcases behave the same on Firefox, Safari and Chrome. I tried both MacOS and Windows.

Regarding why no load event is fired. In general, we are loading a page and during the load handler, synchronously write to the document, but no second load event is fired. As noted in c11, if the write happens asynchronously, there is a second load event. From stepping through the execution paths, they differ by the return value of SkipLoadEventAfterClose() in this line. This flag is intentionally set in document.open() iff open is called during the load event.

This does align with the spec, but there is an open issue about it: spec issue 4292

Thanks Vincent.

Which test cases were you testing? I am particularly curious about the testing results of the test cases from bug 1885937 and bug 1840932, which are believed related with this bug.

I tried testcase one through four from this bug and looked at the other two bugs, though these do not have testcases. It seems like the load event is fired correctly on open/write/close.

The webcompat data shows only one broken page, i.e. Bug 1840932. I can verify the page is still broken, but I would not know how to diagnose the issue. It appears that the load event is not fired on the iframe on that page, but when I attach a debugger, the page starts working.

After Vincent's investigation, we believe this is not a webcompat:platform-bug or blocks the site report bug 1840932. I clear the keyword and dependency field to reflect the findings.

No longer blocks: 1885937
Keywords: webcompat:platform-bug
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: