Closed Bug 233745 Opened 21 years ago Closed 21 years ago

document.getElementById returns NULL until initial layout is complete

Categories

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

Product:
Core
Component:
DOM: Core & HTML
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 178258

People

(Reporter: shaver, Unassigned)

References

(
URL
)

Details

It is my considered opinion that the first alert should find the div in the DOM, just as the second one does. dbaron suspects that it's a missing FlushPendingNotifications call somewhere. IE has the same behaviour as we do, FWIW.
Actually, this is a known issue. No explicit <body> means that the <script> actually gets pushed up into the <head> (check in DOM inspector). So at the time when the script executes the <div> is in fact not in the document. I'm not sure why we have this wacky parser behavior, but CNavDTD goes to great lengths to produce it. See http://lxr.mozilla.org/seamonkey/source/htmlparser/src/CNavDTD.cpp#1819 FlushPendingNotifications wouldn't help in any case, since it doesn't change the content model (nodes are actually hooked up eagerly; the hookups are just notified on lazily). > IE has the same behaviour as we do, FWIW. Maybe IE produces the same content model too? That would explain a good deal...
Ah, that's it. *** This bug has been marked as a duplicate of 178258 ***
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → DUPLICATE
(In reply to comment #1) > I'm not sure why we have this wacky parser behavior, but CNavDTD goes to great > lengths to produce it. IE does it too, which is probably why. (CNavDTD involved a LOT of intentional reverse engineering of IE4 and NN4.)
Component: DOM: Core → DOM: Core & HTML
QA Contact: ian → general
You need to log in before you can comment on or make changes to this bug.