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)

Product:
Core
Component:
DOM: Core & HTML
Platform:
Other
Windows 2000
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: kchen, Unassigned)

Details

(Keywords: testcase)

Attachments

(1 file, 3 obsolete files)

testcase (warning: browser may freeze a little. this is normal)
256 bytes, 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> ------------------------------------------------------
->DOM
Assignee: asa → jst
Component: Browser-General → DOM Level 0
QA Contact: doronr → desale
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.
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.
Is this still a problem in recent nightlys?
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?
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
Attachment #44888 - Attachment mime type: application/octet-stream → application/zip
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.
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
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
Mass-reassigning bugs to dom_bugs@netscape.com
Assignee: jst → dom_bugs
Attached file frame2 (obsolete) —
Attachment #44888 - Attachment is obsolete: true
Attached file frame1 (obsolete) —
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
wfm
Status: NEW → RESOLVED
Closed: 22 years ago
Keywords: qawanted → testcase
Resolution: --- → WORKSFORME
Summary: onload() does not fire properly on build ID = 2001080110 → frame onload() does not fire if there's a slow rendering frame
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: