Closed
Bug 94025
Opened 23 years ago
Closed 22 years ago
frame onload() does not fire if there's a slow rendering frame
Categories
(Core :: DOM: Core & HTML, defect, P3)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: kchen, Unassigned)
Details
(Keywords: testcase)
Attachments
(1 file, 3 obsolete files)
(deleted),
text/html
|
Details |
I have a page (frame.asp) contains two frames(Header2.asp & code2.asp).
Both Header2 and Code2 pages have onload event.
If code2.asp takes too much time to generate client side javascript, the onload
event on code2.asp will not be fired.
The onload event at Header2 page fires a setinterval function. If I increase
the time of the interval (from 150 to 400) time on Header2 or decrease the time
code2 used to generate client side javascript, the onload event on code2 will
be fired.
This happens to Mozilla 0.9.3 build ID = 2001080110
This does not happen to Mozilla 0.9.2 build ID= 2001062815
frame.asp---------------------
<%@ Language=JavaScript %>
<html>
<head>
<title>Expandable Web Development</title></head>
<frameset frameborder="0" framespacing="0" border="0" cols="*" rows="41,*,30">
<frame marginwidth="0" src="Header2.asp" name="code" noresize
scrolling="no" frameborder="0">
<frame marginwidth="5" src="code2.asp" name="menu" noresize
scrolling="auto" frameborder="0">
</frameset>
<noframes>
</noframes>
</frameset>
</html>
----------------------------------
Header2.asp------------------
<%@ Language=JavaScript %>
<script LANGUAGE="javascript">
function change_link(){
if (parent.frames[1] && parent.frames[1].document && parent.frames
[1].document.forms[0]) {
}
}
</script>
<HTML><HEAD><TITLE></TITLE></HEAD>
<body onload="setInterval('change_link()', 150);">
</body></html>
----------------------------------------------------------
code2.asp--------------
<%@ Language=JavaScript %>
<html>
<head>
<title></title>
<%
Response.Write('<scr' + 'ipt type="text/javascript"> \n');
for (iii=0; iii <500000; iii++);
Response.Write('</scr' + 'ipt> \n');
%>
</head>
<body onload="top.alert('5'); " bgcolor="#ffffff" >
</body>
</html>
------------------------------------------------------
Reporter | ||
Comment 1•23 years ago
|
||
Comment 2•23 years ago
|
||
->DOM
Assignee: asa → jst
Component: Browser-General → DOM Level 0
QA Contact: doronr → desale
Comment 3•23 years ago
|
||
Hi Kuantai Chen,
I have some trouble understanding the bug report, because there are some
unfamiliar tags in the sample code. What is <%@ %>? What is Response and Write?
Also the testcase is impossible to debug because I don't have the proper font
thus it is unreadable. It would help very much if you could produce a testcase
in western fonts, since all the developers working on the DOM use those.
Thanks alot in advance,
-Fabian.
Comment 4•23 years ago
|
||
Comments from the reporter received in personal mail:
"It is ASP code. I don't understand the problem about fonts.
If you mean you can not read it from your source, here I copied the example
code read it as you read the email [Insert the code copied from the original bug
report].
Thank you for your help."
I meant that what I can't read is the testcase you attached. It shows lots of
"???????" (question marks). Anyway thanks for the follow-up.
Comment 5•23 years ago
|
||
Is this still a problem in recent nightlys?
Comment 6•23 years ago
|
||
It is generally a very bad idea to fire onload event handlers from frames
affecting other frames. More than likely your testcase is generating a
JavaScript error which is terminating the whole mess.
Try firing your onload event handler from the frameset instead.
Also, can you post the code after the ASP is done generating it?
Updated•23 years ago
|
Attachment #44888 -
Attachment description: it contains 3 ASP pages to reproduce the error → it contains 3 ASP pages to reproduce the error (zipfile)
Attachment #44888 -
Attachment mime type: text/plain → application/octet-stream
Updated•23 years ago
|
Attachment #44888 -
Attachment mime type: application/octet-stream → application/zip
Comment 7•23 years ago
|
||
I've put a temporarily testcase up at http://bug94025.kruideniernet.nl/frame.asp.
I've made the following changes to try and reproduce this bug:
In Header2.asp I've changed the setInterval from 150 to 4000. (also tried 400)
In code2.asp I've changed the for loop from 500000 to 5000.
As I understand, this bug causes the alert('5') NOT to be generated.
Using Linux Build-ID 2001080110 I see the alert. This could be caused by the
transparent proxy I'm currenly behind.
Comment 8•23 years ago
|
||
Could you please change the setInterval to 100 (or even 50) in the testcase?
And change the 5000 back to 500000? _Low_ values of setinterval combined with
_long_ loops in the other file are what triggers this bug.
I'm 99% certain that avincent's explanation is the right one.
Updated•23 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 9•23 years ago
|
||
SEVERITY = LOW [(1)No Crash, (2)Nice catch of functional failure, (3)No Cosmetic
failure]
VISIBILITY = HIGH [(1)There may be real website usage. (2)Gets one point of
compatibility with other browsers since it works very well on other browsers.
(3)Gets one more point on compliance with adopted techonology which is JS]
PRIORITY = VISIBILITY * SEVERITY
Hence Priority = p3
adding word "qawanted" because I'm setting this priority on available data & if
someone feels otherwise then please investigate this more & feel free to change
this priority.
Keywords: qawanted
Priority: -- → P3
Comment 11•22 years ago
|
||
Attachment #44888 -
Attachment is obsolete: true
Comment 12•22 years ago
|
||
Comment 13•22 years ago
|
||
The testcase is worksforme moz2003040708/win98
Mozilla would freeze a little, then prompt if the user wants to
continue a slow scripts. Then both frame's onload events are fired.
MSIE5 would freeze a little, fire top frame's onload event, ask
if the user wishes to continue the script, then fired bottom frame's
onload event (the frame w/ slow script)
Attachment #119957 -
Attachment is obsolete: true
Attachment #119958 -
Attachment is obsolete: true
Comment 14•22 years ago
|
||
wfm
You need to log in
before you can comment on or make changes to this bug.
Description
•