See attached test case.
Basically, getElementsByTagName() returns a value like you've already executed the code that *follows* it. If you remove the later code, the earlier code behaves as expected.
Google Chrome 9.0.576.0 (Official Build 65344) dev
Works in Firefox 3.6.12.
Created attachment 73834 [details]
html file showing problem
(Note that this only dumps to the JS console, so you need Firebug installed on Firefox to test it.)
Created attachment 73836 [details]
Here's a better example, where we flip a coin to decide whether to remove the node or not. Load this, bring up the console, repeatedly hit f5 and boggle at the first line of output changing.
I guess something is printing the actual value of getElementsByTagName too late -- we always seem to successfully get the first node, whether or not the console.log thinks it exists.
I think getElementsByTagName is returning a live node list. You're then modifying the node list. The question is when we read the value of the node list to print. With the inspector using an async API, I can see why this might occur after later than you expect.
This seems like an inspector bug and not a DOM bug. If you log document.getElementsByTagName('ul').length instead of just document.getElementsByTagName('ul'), you will see that the first log has two elements and the second log as one element.
Changing component to Web Inspector.
With another day's perspective on my code.
=> prints the list with only the second one
var x = document.getElementsByTagName('ul');
=> x successfully is the first (missing) item.
So it's clear that document.getElementsByTagName is returning the right thing, and it's just the console.log that is confusing. I'll retitle the bug to something less mysterious.
A bit later, but thanks for the great repro Evan. (and folks for the help)
Also downstream ticket is at http://crbug.com/50316
*** This bug has been marked as a duplicate of bug 35801 ***