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

RESOLVED WONTFIX

Status

()

RESOLVED WONTFIX
16 years ago
10 years ago

People

(Reporter: czapszys, Assigned: jst)

Tracking

Trunk
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

16 years ago
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

16 years ago
Created attachment 100172 [details]
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.
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

16 years ago
Whiteboard: WONTFIX?
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.
OK.  jst agrees that this is wontfix unless there's a very short and simple
patch.  Marking so.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → WONTFIX
Summary: el.getElementsByTagName() fails on detached nodes. → el.getElementsByTagName() fails on detached nodes. [1.0 branch only]
Whiteboard: WONTFIX?

Updated

10 years ago
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.