Closed
Bug 170214
Opened 22 years ago
Closed 22 years ago
el.getElementsByTagName() fails on detached nodes. [1.0 branch only]
Categories
(Core :: DOM: Core & HTML, defect)
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: czapszys, Assigned: jst)
Details
Attachments
(1 file)
1.57 KB,
text/html
|
Details |
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.
Reporter | ||
Comment 1•22 years ago
|
||
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•22 years ago
|
||
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•22 years ago
|
||
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.
Updated•22 years ago
|
Whiteboard: WONTFIX?
Comment 4•22 years ago
|
||
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•22 years ago
|
||
OK. jst agrees that this is wontfix unless there's a very short and simple patch. Marking so.
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago
Resolution: --- → WONTFIX
Summary: el.getElementsByTagName() fails on detached nodes. → el.getElementsByTagName() fails on detached nodes. [1.0 branch only]
Whiteboard: WONTFIX?
Component: DOM: Core → DOM: Core & HTML
QA Contact: stummala → general
You need to log in
before you can comment on or make changes to this bug.
Description
•