Closed Bug 77989 Opened 24 years ago Closed 24 years ago

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

Categories

(Core :: Layout, defect, P2)

Product:
Core
Component:
Layout
Platform:
x86
All
Type:
defect

Tracking

()

Status:
RESOLVED DUPLICATE of bug 81980
Milestone:
mozilla1.0

People

(Reporter: jruderman, Assigned: nisheeth_mozilla)

References

(
URL
)

Details

(Keywords: perf, regression, testcase, 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. data:text/html,foo data:text/plain,bar 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. <http://www.squarefree.com/htmledit/>. 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 loads. 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).
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.2
Another test for this: http://www.hixie.ch/tests/adhoc/data/003.html 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.
URL: data:text/html,foopy
Severity: normal → major
Keywords: mozilla1.0 → mozilla0.9.1, perf
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
Status: ASSIGNED → NEW
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. http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=4%2F24%2F2001&maxdate=4%2F26%2F2001&cvsroot=%2Fcvsroot 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.
Status: NEW → ASSIGNED
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
Status: ASSIGNED → NEW
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
->0.9.9
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.
URL: javascript:document.writeln("Help me,... → javascript:document.writeln("Help me,...
Status: NEW → ASSIGNED
"javascript:document.writeln("Help me, Dave Hyatt...you're my only hope");document.close();" 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 ***
URL: javascript:document.writeln("Help me,... → javascript:document.writeln("Help me,...
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.