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

RESOLVED DUPLICATE of bug 81980

Status

()

defect
P2
normal
RESOLVED DUPLICATE of bug 81980
18 years ago
5 years ago

People

(Reporter: jruderman, Assigned: nisheeth_mozilla)

Tracking

({perf, regression, testcase})

Trunk
mozilla1.0
x86
All
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [Hixie-P4], URL)

(Reporter)

Description

18 years ago
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>
(Reporter)

Updated

18 years ago
Keywords: regression

Comment 1

18 years ago
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]
(Reporter)

Comment 3

18 years ago
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

Comment 4

18 years ago
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
(Reporter)

Comment 5

18 years ago
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

Comment 6

18 years ago
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().

Updated

18 years ago
Blocks: 71668

Comment 7

18 years ago
please os->all, I am seeing the same problem on Linux.
OS: Windows 98 → All

Comment 8

18 years ago
->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 → ---

Comment 9

18 years ago
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
(Reporter)

Comment 10

18 years ago
I think the textarea loses focus because of bug 77675, web pages steal focus
when they load.
(Assignee)

Comment 11

18 years ago
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

Updated

18 years ago
Target Milestone: mozilla0.9.3 → mozilla0.9.4
(Assignee)

Comment 12

18 years ago
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
(Reporter)

Comment 13

18 years ago
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 → ---

Updated

17 years ago
Blocks: advocacybugs
(Assignee)

Comment 16

17 years ago
->0.9.9
Target Milestone: --- → mozilla0.9.9
(Assignee)

Comment 17

17 years ago
Won't make 0.9.9.  -> 1.0
Target Milestone: mozilla0.9.9 → mozilla1.0
Keywords: mozilla1.0
(Reporter)

Comment 18

17 years ago
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
(Assignee)

Comment 19

17 years ago
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.
(Assignee)

Comment 20

17 years ago
"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 ***
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.