I replace an element in Javascript by : y = cloneNode( x ) removeChild( x ) Then I try to access "y" using GetElementsByName, BUT I get an "undefined value" It looks like some pointers are not handled correctly. In the example, clicking one of the the lines lead to an error.
sounds related to bug #8080
(In reply to comment #0) > I replace an element in Javascript by : > y = cloneNode( x ) > removeChild( x ) > > Then I try to access "y" using GetElementsByName, BUT I get an "undefined > value" Have you added "y" to the document when you try to use getElementsByName()? If not, it won't be found. Please post a test case. The URL on the bug seems to be inaccessible now: http://www.lptl.jussieu.fr/users/bernu/pub/fred.html Thanks!
The test case is accessible now, but after a quick look at it I'm not able to determine what to do to reproduce the described bugs. Clicking on the links has no visible effect. A minimal test case with clear instructions which makes clear what you consider to be the PASS/FAIL condition would be great!
(In reply to comment #3) > The test case is accessible now, but after a quick look at it I'm not able to > determine what to do to reproduce the described bugs. Clicking on the links > has no visible effect. A minimal test case with clear instructions which makes > clear what you consider to be the PASS/FAIL condition would be great! > The messages appear in the console.log : Clicking on the link gives : my_a a-2 <DOMNodeList: 0x5387dc0> 2 <DOMNodeList: 0x4c0be0> 2 Undefined value line 21 The first 4 lines are ok (of course, thenode addreesses will be different each time) The last line shows the error.
Created attachment 16385 [details] Test case from URL
The reason "undefined value" is being returned in the test case is that NodeLists indexing is 0 based, not 1 based. Therefore, xs[2] does not exist.
(In reply to comment #6) > The reason "undefined value" is being returned in the test case is that > NodeLists indexing is 0 based, not 1 based. Therefore, xs[2] does not exist. > Right. Sorry for posting this. I have a problem on a more complicated case and I thoughI found where was the problem. I go back to work more on it Sorry again for that
I think I found the real problem. (http://www.lptl.jussieu.fr/users/bernu/pub/fred.html) the Javascript is reduced to function del( ){ var divs = document.getElementsByName( "my_a" ) ; divs[0].parentNode.removeChild( divs[ 0 ] ) ; console.log( divs.length ) ; console.log( divs[0].id ) ; console.log( divs[1].id ) ; } and the HTML to <body> <div href="" id="a-1" name="my_a" >div 1</div> <div href="" id="a-2" name="my_a" >div 2</div> <input type="submit" onclick="del() ; return false;" /> </body> The result in the console is 2 a-1 Null value error on line accessing divs[1].id What I understand is : getElementsByName gives a list of 2 nodes. Removing the first div leaves the nodeList divs with 2 elements. Accessing the first element surprinsingly worked here (but might not in a more complicate case) Accessing the second element fails on Safari. On FireFox, the result is more consistent : 1 a-2 error divs[1] has no property. Thus, removing an element in a list is the problem that WebKit is not doing as other browsers. After removing divs[0], divs.length=1
Bernard, can you please attach a standalone test case that matches what you describe? This will make it much easier to verify that we're all looking at the same thing.
(In reply to comment #9) > Bernard, can you please attach a standalone test case that matches what you > describe? This will make it much easier to verify that we're all looking at > the same thing. > I did put the following link at the top of my comment. I just verified the example is accessible http://www.lptl.jussieu.fr/users/bernu/pub/fred.html
Sorry about that, I totally missed that link :)
I would guess removeChild is failing to invalidate the cache kept by the divs collection that getElementsByName returns.
Created attachment 16541 [details] further reduced test case
This is a regression from shipping Safari/WebKit.
Note that this bug reproduces in WebKit nightly build r11976 (earliest nightly build available).
<rdar://problem/5524756>
My guess is this was hyatt's qname patch: http://trac.webkit.org/projects/webkit/changeset/9824 I don't see why rootNodeChildrenChanged: // Other methods (not part of DOM) virtual void rootNodeChildrenChanged() { } virtual void rootNodeAttributeChanged() { NodeList::rootNodeChildrenChanged(); } should be empty like that. I expect it really should invalidate its length cache, if nothing else.
Well, it may still have been broken by the qname change (I'm unsure of that). That's where the rootNodeChildrenChanged() function came from as far as I can tell. However, it does not appear that rootNodeChildrenChanged() is the right function to call. As mjs suggested, it's simply that a node doesn't know to tell the document to invalidate its name caches when it's removed. A node removed anywhere in the tree should check its name and then notify the caches. A node whos name changes anywhere in the tree will need to do the same. It looks like bool EventTargetNode::dispatchSubtreeModifiedEvent(bool sendChildrenChanged) is the responsible function. Which isn't very smart about what nodes it notifies, it just does a blanket notification it seems. It looks like the current system indicates that the empty override for rootNodeChildrenChanged() should simply be removed (and that will fix the problem). There might be a more efficient solution to build however.
Created attachment 16584 [details] a fix If this is approved for trunk, please someone else land it. If it's approved only for feature-branch, I'm happy to land the patch.
Comment on attachment 16584 [details] a fix r=me
Landed in r26585 after adding a LayoutTest ChangeLog entry.