It might be a dupe but there are so many JS bugs filed that I coudd not find one that matched mine. If in a JS function mozilla is asked to use a CSS property which was not set, it falls into an infinite loop and stops processing the rest of the page. I created a testcase with a <div> that has its "left" position set in an inline CSS style but not its "top " position. If I ask Mozilla to display the value of the Left and Top positions of the <div>, it displays the value of the Left position which was set (after a loong time on an Athlon 1700XP !) but seems to fall into an infinite loop when it has to display the undefined Top value. The mozilla logo keeps on spinning and the browser keeps on working with a 2% CPU usage. IE displays the results instantly and gives me the expected "NaN" value for the property I had not set. Pascal
Created attachment 80267 [details] testcase showing how Mozilla gets stucked when asked to display the value of an undefined CSS property
Seeing this using 2002041711 (RC1) and 2002042006 on Win2k.
confirmed with 1.0RC1, Linux - someone change the OS please
Status: UNCONFIRMED → NEW
Ever confirmed: true
Hardware: PC → All
critical, not blocker -> dom style
Assignee: rogerl → jst
Severity: blocker → critical
QA Contact: pschwartau → ian
This is not a hang (as anyone could have discovered by simply pressing the "stop" button). Here is what happens: 1) We get the style object. 2) We get the "left" of the style object and document.write() it. This destroys the initial page, together with the various script variables defined on it, since document.write() calls an implicit document.open(). 3) We attempt to parseInt(gk.left) and get a JS error (anyone bothered to look at their JS console?) since gk is no longer defined. 4) We're in the middle of a document.write() and never call document.close(), so the throbber keeps spinning (bug 81980). A possible bug here is the "This destroys the initial page, together with the various script variables". Not sure whether we should be doing that or not.. over to DOM0 for consideration.
Severity: critical → normal
Component: DOM Style → DOM Level 0
QA Contact: ian → desale
Thank you Boris for this explanation, the bug should indeed probably be marked Invalid except if we consider that Opera/IE are right when they do not destroy the script variables.
Severity: normal → blocker
OS: All → Windows 98
QA Contact: desale → pschwartau
Hardware: All → PC
restoring form fields that got munged. :)
Severity: blocker → normal
OS: Windows 98 → All
QA Contact: pschwartau → desale
Hardware: PC → All
Dup of bug 114461?
Yeh, that's it. :) *** This bug has been marked as a duplicate of 114461 ***
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.