doc.write() without doc.close() waits 1.2s before painting




19 years ago
5 years ago


(Reporter: jruderman, Assigned: nisheeth_mozilla)


({perf, regression, testcase})

Dependency tree / graph

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [Hixie-P4], )

The following URLs take much longer to load in 042604 than they do in 042404 
(Win98).  In 04/26, they display a white page for about a second and then show 
their content; in 04/24, the content is shown right away.


One effect of this bug is that my the bottom frame of my html editor is blank 
unless you pause typing for a full second.

Assigning to hyatt because he owned bug 77002, "Avoid eager painting of Web 
page content in SeaMonkey", which might have caused this regression.

I noticed that in both 04/24 and 04/26, onload events for data:text/html are 
ignored.  This might be why nothing is painted until a second after the page 

data:text/html,<body onload="alert(3)">baz</body>
Keywords: regression
The problem here is that the data URLs don't fire LoadComplete (and don't 
execute onload).
Target Milestone: --- → mozilla0.9.2
Another test for this:

I can't imagine that onload handlers of data: URLs are the most common feature on 
the web, so I contest the "major" severity... however I do think this should be
a Mozilla 1.0 blocker.
Keywords: mozilla1.0, testcase
Whiteboard: [Hixie-P4]
I set this as major because I use data: urls often while testing Mozilla (what 
does Mozilla do if I...), and having to wait a second for them to load is 
annoying.  I'll lower the severity though.
Severity: major → normal
Need to fix for .9.1, javascript: has the same problem.  Testcase is simple 
enough -- see URL.
Severity: normal → major
Summary: simple data: urls take about a second to load → data: and javascript: documents wait 1.2s before painting
Clarifying summary: javascript:"foopy" is a javascript: document, whereas 
javascript:document.writeln("foopy") is a javascript-generated document.  
javascript: documents (which are rare) aren't affected by this bug, but 
javascript-generated documents are.

"Onload doesn't fire in javascript-generated documents" is bug 57636, assigned 
to nisheeth as P1/blocker/mozilla0.9.1.  "Onload doesn't fire for data: 
documents" is also mentioned in that bug, but I don't think it's covered by 
that bug.

It might be tricky to get the painting delay to work correctly for javascript-
generated documents.  If some javascript code does a document.close(), Mozilla 
can fire an onload event then, but if it only calls write(), Mozilla won't have 
any way to know when the document is complete.  I don't know how common code is 
that doesn't close(), but other browsers are forgiving of not calling close().
Summary: data: and javascript: documents wait 1.2s before painting → javascript-generated and data: documents wait 1.2s before painting
Even if you close() the delay persists.  In any case, I'm not sure how 
conceptually correct it is to fire an onload on close().
Blocks: 71668
please os->all, I am seeing the same problem on Linux.
OS: Windows 98 → All
->nisheeth per hyatt, content created using document.writeln should be calling 
loadComplete in documentViewer. clearing target for re-triage.
Assignee: hyatt → nisheeth
Target Milestone: mozilla0.9.2 → ---
The testcase is now completely broken. Not only there is a long delay, but if
you press space in the textarea it (sometimes) losts focus so you have to click
in it. Also removing the 0.9.1 keyword since it is far away.
Keywords: mozilla0.9.1
I think the textarea loses focus because of bug 77675, web pages steal focus
when they load.
I just want to point out that the regression is not due to any checkins by me.
points to the checkins made between 4-24 and 4-26.

We currently fire the onload event on document.written() content when
document.close() is called (see bug 81980).  That is the root cause of this bug.

Setting target milestone to 0.9.3.
Target Milestone: --- → mozilla0.9.3
Target Milestone: mozilla0.9.3 → mozilla0.9.4
Bulk re-assign of my 0.9.4 bugs to Heikki.  I will not have the cycles to work
on these bugs while Clayton is on sabbatical for the next six weeks.
Assignee: nisheeth → heikki
Target Milestone: mozilla0.9.4 → mozilla0.9.5
Target Milestone: mozilla0.9.5 → mozilla0.9.6
See also bug 102779, "data: URLs never fire onload handlers".  Fixing that 
would take care of the data: case but not the JS case.
Target Milestone: mozilla0.9.6 → mozilla0.9.8
Adding nsbeta1 keyword to all regressions so they *get some love* and attention.
Keywords: nsbeta1
Nisheeth, here is one tricky perf bug for you...
Assignee: heikki → nisheeth
Target Milestone: mozilla0.9.8 → ---
Blocks: advocacybugs
Target Milestone: --- → mozilla0.9.9
Won't make 0.9.9.  -> 1.0
Target Milestone: mozilla0.9.9 → mozilla1.0
Keywords: mozilla1.0
WFM for data: urls, thanks to bug 102779 which gave them an onload event. 
Restricting summary to the javascript case.
Severity: major → normal
Summary: javascript-generated and data: documents wait 1.2s before painting → doc.write() without doc.close() waits 1.2s before painting
I'm going to try and fix the testcase where document.close() is also called. 
Updating above URL accordingly.  The problems associated with test cases where 
only document.write() is called are covered by bug 81980.
"javascript:document.writeln("Help me, Dave're my only 

displays immediately.

I'm reverting the URL back to just a document.write() without a document.close
() since this bug was originally filed to track that testcase.

The 1.2 s painting delay only happens when the script author does not call 
document.close().  An easy way to fix it on the content side is to actually 
call document.close().  We can try to fix this in the browser, too, but that 
work is lower priority for now and will be tracked by bug 81980 which is on 
Heikki's list and currently futured.

Marking this bug a dupe of 81980.

*** This bug has been marked as a duplicate of 81980 ***
Closed: 18 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.