170214 - el.getElementsByTagName() fails on detached nodes. [1.0 branch only]

Status: RESOLVED WONTFIX

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

Description

[Andrej Czapszys]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020815
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020815

element.getElementsByTagName() can give outdated results for fragments which are
not currently attached to a document.
I have some javascript which effectively does the following:
1) Find or create block node and append to documentFragment.
2) In the block node, find or create text input if necessary.
3) Find input and apply current styles if it exists.
4) Append documentFragement to document.

I'm finding that a .getElementsByTagName() on my detached node
gets cached such that modifications to the fragment keep returning
the old answer (ie. appended elements do not get returned).
This behavior is new in Moz 1.0.1.  It worked as expected in Moz 1.0.


Reproducible: Always

Steps to Reproduce:
1. Create element el1.
2. Query with el1.getElementsByTagName('input')
3. Do el1.appendChild(document.createElement('input'))
4. Query again with el1.getElementsByTagName('input').

Actual Results:  
Last query produces empty list in Moz 1.0.1.

Expected Results:  
Last query should product list with 1 element.

Comment 1

[Andrej Czapszys]

Attachment: Simple example of problem.

This is a simple example of the problem.
Textbox 1 contains JS which works, because getElementsByTagName has
not been called before changing the tree.
Textbox 2 contains JS which demonstrates the problem.

Comment 2

[Andrew Schultz]

regressed on the branch (probably) here  (window between 5-28 and 6-01)
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=MOZILLA_1&branchtype=regexp&dir=mozilla%2Fcontent%2Fbase%2Fsrc&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=05%2F30%2F2002+13%3A00%3A00&maxdate=05%2F30%2F2002+13%3A10%3A00&cvsroot=%2Fcvsroot

but works on the trunk  (probably) here (window between 2002062713 and 2002062904)
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=mozilla%2Fcontent%2Fbase&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=06%2F27%2F2002+18%3A00%3A00&maxdate=06%2F27%2F2002+19%3A00%3A00&cvsroot=%2Fcvsroot
(bug 104603)

I don't know that there will be much enthusiasm about fixing this on the branch...

Comment 3

[Boris Zbarsky [:bzbarsky]]

Andrew is exactly correct.  Note that the code on the branch was broken before
the checkin that breaks this testcase... all you had to do was keep using the
old NodeList instead of asking for a new one (which is something you should do
in any case, since nodelists are live).

Fixing this on branch is well-nigh impossible -- we'd need to land fixes for at
least the CompareTreePosition() stuff as well as the fix for bug 104603 and the
fixes for the two regressions that caused.  Large scary changes and all that.

In other words, suggesting WONTFIX.

Comment 4

[Christopher Aillon (sabbatical, not receiving bugmail)]

I also suggest WONTFIX.  I do not want to land the CTP stuff on the 1.0 branch
as-is.  That is experimental and AIUI, the DOM WG is about to majorly revamp
it's actions and constants.  In fact, I probably need to rename our current impl
or something....

Agreed this is a bug on the branch, but one that is highly unlikely to ever be
encountered by enough people to warrant landing all this high risk stuff into
the 1.0.x branch.

Comment 5

[Boris Zbarsky [:bzbarsky]]

OK.  jst agrees that this is wontfix unless there's a very short and simple
patch.  Marking so.