Closed
Bug 54151
Opened 24 years ago
Closed 24 years ago
HTMLElement.offsetParent incorrectly points to itself, Was: Browser locks up during mouseover/mouseout event when activating Dynamic Menu implemented using DOM
Categories
(Core :: Layout, defect, P3)
Core
Layout
Tracking
()
Future
People
(Reporter: bc, Assigned: jst)
References
()
Details
Attachments
(1 file)
|
627 bytes,
text/html
|
Details |
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; m18) Gecko/20000925
BuildID: 2000092508
This web site uses the DOM to generate a dynamic menu system. It has worked for
both IE and Mozilla from Mozilla M16 through M18 / 2000090508. For the last week
or so, whenever I try to access the site using Mozilla M18 nightly builds, the
browser will lock up whenever I move the mouse cursor over one of the menu
elements. I am assuming this is related to the DOM 2 Event handling, but don't
know for certain.
Reproducible: Always
Steps to Reproduce:
1. visit http://www.mindspring.com/~bobclary/
2. move mouse over one the menu items.
Actual Results: Browser locks up, consumes ~100% of CPU, and continually
allocates and releases small blocks of memory.
Expected Results: Open the menu item.
|
||
Comment 1•24 years ago
|
||
Confirmed on Linux build 20000925. Marking OS as all; marking severity
as critical, since this is just about as bad as a crash.
Severity: normal → critical
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows 2000 → All
|
Reporter | |
Comment 2•24 years ago
|
||
The problem is caused by the HTMLElement's offsetParent pointing to itself.
This site calculates Element positions on the page by adding offset properties
from it's offsetParents until it reaches an offsetParent of null. The
HTMLElement.offsetParent == HTMLElement causes an infinite loop in the script.
Changing summary to HTMLElement.offsetParent incorrectly points to itself.
Changing Component from DOM Level 2 to HTML Element.
Note that since this bug makes the site unusable, a work around will be
implemented to prevent an infinite loop from occuring in order to allow
Mozilla clients to access the site. See the following HTML Test Case for an
example of the problem:
<HTML>
<HEAD>
<script language="javascript">
function init()
{
var node = document.body;
if (node)
{
alert('document.body = ' + node +
(node ? (', nodeName = ' + node.nodeName) : ''));
node = node.offsetParent;
alert('document.body.offsetParent = ' + node +
(node ? (', nodeName = ' + node.nodeName) : ''));
if (node)
{
node = node.offsetParent;
alert('document.body.offsetParent.offsetParent = ' + node +
(node ? (', nodeName = ' + node.nodeName) : ''));
}
}
}
</script>
</HEAD>
<BODY onload="init()">
</BODY>
</HTML>
Component: DOM Level 2 → HTML Element
Summary: Browser locks up during mouseover/mouseout event when activating Dynamic Menu implemented using DOM → HTMLElement.offsetParent incorrectly points to itself, Was: Browser locks up during mouseover/mouseout event when activating Dynamic Menu implemented using DOM
|
|
Reporter | |
Comment 3•24 years ago
|
||
|
|
Reporter | |
Comment 4•24 years ago
|
||
nsGenericHTMLElement::GetOffsetParent calls nsGenericHTMLElement::GetOffsetRect
to get the bounding frame and a pointer to the parent Element. GetOffsetRect
will return as the offsetParent the documentElement (the 'HTML' Element) if it
is called for either the 'BODY' Element or the 'HTML' Element. I believe the
proper behaviour is return null for the 'BODY' Element's offsetParent.
It appears that although GetOffsetRect is called by the other 'Offset' methods,
the only method that uses the parent parameter is GetOffsetParent.
This is my first proposed patch so be kind... ;)
Index: nsGenericHTMLElement.cpp
===================================================================
RCS file: /cvsroot/mozilla/layout/html/content/src/nsGenericHTMLElement.cpp,v
retrieving revision 1.210
diff -u -r1.210 nsGenericHTMLElement.cpp
--- nsGenericHTMLElement.cpp 2000/09/15 06:15:31 1.210
+++ nsGenericHTMLElement.cpp 2000/10/03 04:10:25
@@ -632,6 +632,7 @@
if (parentContent) {
// If we've hit the document element, break here
if (parentContent.get() == docElement.get()) {
+ parent = nsnull;
break;
}
nsCOMPtr<nsIAtom> tag;
@@ -650,7 +651,7 @@
parent->GetParent(&parent);
}
- *aOffsetParent = parentContent;
+ *aOffsetParent = (parent) ? parentContent : nsnull;
NS_IF_ADDREF(*aOffsetParent);
// For the origin, add in the border for the frame
The severity for this bug should probably be reduced, but I am loath to make
such changes. Since the Component has changed from DOM Level 2 to HTML Element,
it is also probable that it should be reassigned. Can someone help out with this?
Thanks.
|
Assignee | |
Comment 5•24 years ago
|
||
Hey, not bad for your first patch :-)
I would however, like to propose this patch in stead (you're setting 'parent' to
null and thus the border adjustments futher down in the method will not be done
and could potentially make offsetXXX be incorrect for the body element, I could
be wrong tho, didn't look that closely at the code):
Index: layout/html/content/src/nsGenericHTMLElement.cpp
===================================================================
RCS file: /cvsroot/mozilla/layout/html/content/src/nsGenericHTMLElement.cpp,v
retrieving revision 1.210
diff -u -r1.210 nsGenericHTMLElement.cpp
--- nsGenericHTMLElement.cpp 2000/09/15 06:15:31 1.210
+++ nsGenericHTMLElement.cpp 2000/10/03 08:04:37
@@ -591,6 +591,8 @@
{
nsresult res = NS_OK;
+ *aOffsetParent = nsnull;
+
aRect.x = aRect.y = 0;
aRect.Empty();
@@ -638,6 +640,9 @@
// If the tag of this frame matches the one passed in, break here
parentContent->GetTag(*getter_AddRefs(tag));
if (tag.get() == aOffsetParentTag) {
+ *aOffsetParent = parentContent;
+ NS_IF_ADDREF(*aOffsetParent);
+
break;
}
}
@@ -650,9 +655,6 @@
parent->GetParent(&parent);
}
- *aOffsetParent = parentContent;
- NS_IF_ADDREF(*aOffsetParent);
-
// For the origin, add in the border for the frame
const nsStyleSpacing* spacing;
nsStyleCoord coord;
Comments?
I don't however have any other choice than to mark this bug future tho since
there's no way this will be considered a bad enough problem for the Netscape 6
branch...
Severity: critical → normal
Status: NEW → ASSIGNED
Hardware: PC → All
Target Milestone: --- → Future
|
|
Reporter | |
Comment 6•24 years ago
|
||
Whatever works and you are comfortable with is fine with me.
Futuring this or any other bug is fine with me just so long as I find a work
around. Also, having this bug on record will help anyone else find a work
around if they run into the same problem I did.
Thanks.
|
|
Assignee | |
Comment 7•24 years ago
|
||
Turns out that this caused a hang on reuters.com which is a highly traficed
site, the bug for the hang is bug 54892 and since that bug is rtm++ I'll dupe
this bug...
*** This bug has been marked as a duplicate of 54892 ***
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
SPAM. HTML Element component deprecated, changing component to Layout. See bug
88132 for details.
Component: HTML Element → Layout
You need to log in
before you can comment on or make changes to this bug.
Description
•