Closed Bug 2839 Opened 26 years ago Closed 26 years ago

firstChild of HTMLHeadElement refers back to HTMLHeadElement

Categories

(Core :: DOM: Core & HTML, defect, P1)

Product:
Core
Component:
DOM: Core & HTML
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: ckritzer, Assigned: vidur)

Details

When assigning HTMLHeadElement.firstChild to a variable, the object thinks it is HTMLHeadElement instead of HTMLTitleElement. Additional comment: when you remove the <!DOCTYPE.........> line, the object parses correctly. First discovered for all platforms: - 99022 MacOS 8.5 - 99022 Win95 - 99022 Linux RedHat 5.2 Bug still exists on all platforms for: - 99033 MacOS 8.5 - 99033 Win95 - 99033 Linux RedHat 5.2 Here's the HTML to test this: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN"> <HTML> <HEAD> <TITLE>bug.html</TITLE> </HEAD> <BODY> <SCRIPT TYPE="text/javascript"> // document.HTMLHtmlElement.HTMLHeadElement var helmHead = document.firstChild.firstChild; // helmHead.HTMLTitleElement var foo = helmHead.firstChild; document.write("<h2>Bug#</h2>"); document.write("Expected Result = [object HTMLTitleElement]<BR>"); document.write("foo = " + foo + "<BR>"); </SCRIPT> </BODY> </HTML>
Setting all current Open Critical and Major to M3
per leger, assigning QA contacts to all open bugs without QA contacts according to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser
QA Contact: 4015 → 4120
QA contact re-assigned according to the product areas we're currently working on.
Status: NEW → RESOLVED
Closed: 26 years ago
Resolution: --- → INVALID
This is correct. document.firstChild is the HTML element and it's first child is the HEAD element.
Status: RESOLVED → REOPENED
Status: REOPENED → ASSIGNED
Resolution: INVALID → ---
I agree with your statement Vidur, and I apologize for not clearly stating the bug. What is happeninn is the HTMLHeadElement.firstChild thinks it is [HTMLHeadElement]. What appears to be happening is that the first child of the HTMLHeadElement is not pointing to [HTMLTitleElement], but rather pointing recursively @ itself [HTMLHeadElement]. Am I making sense? Reopening and setting back to ASSIGNED.
Target Milestone: M3 → M4
Oops! You're right and I've actually found the cause of the bug - in fact there are two. The first is that the DOCTYPE declaration is treated as a comment by the parser and is incorrectly placed by the HTMLContentSink inside the head. The second is that comment nodes are not creating their script equivalents correctly. The second is easy to fix, the first is not. As you've noticed, taking out the DOCTYPE declaration fixes the problem. I don't see this as a show-stopper and I'm going to move it off the M3 radar.
After my fix goes in for Comment nodes being reflected correctly, this should be DUPed with 3874.
Status: ASSIGNED → RESOLVED
Closed: 26 years ago → 26 years ago
Resolution: --- → FIXED
Both problems have been fixed, but I can't seem to get a working build to check them on. Chris, please verify.
There appears to be a bug (not being able to display tables) blocking regression of this one...I'll regress this as soon as the other one's cleared up...
Status: RESOLVED → VERIFIED
Okay, I found a way to regress this in spite of the display bug and it is indeed closed. Sorry to take so long on it Vidur; Good job finding & fixing it! Marking Verified on 041999 build for MacOS, Win95 & RedHat Linux 5.2.
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.