JavaScript: Unexpected behaviour with querying childNodes of Frameset-Element

RESOLVED INVALID

Status

()

Core
DOM: Core & HTML
RESOLVED INVALID
13 years ago
10 years ago

People

(Reporter: R. Koenig, Unassigned)

Tracking

1.8 Branch
x86
Windows XP
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

(Reporter)

Description

13 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5

When querying the childNodes of a frameset-Element i am getting back not only an array of the nested frame-elements but also empty textelements.

e.g.
var aFrames = document.getElementById("FrameSet").childNodes;
Returns an array of elements. Elements are alternating {Text} holding a value of "\n" and {HTMLFrameElement}

Former versions of Firefox and other browser (e.g. MozillaSuite 1.7.12) i'm using return the FrameElements only.

Reproducible: Always

Steps to Reproduce:
1.create Frameset
2.query childnodes of frameset var aFrames = document.getElementById("FrameSet").childNodes;


Actual Results:  
Returns an array of elements. Elements are alternating {Text} holding a value of "\n" and {HTMLFrameElement}

Expected Results:  
Returns an array of elements {HTMLFrameElement}

Comment 1

13 years ago
If possible could you attach a minimized testcase to this bug please.

->Core:DOM
Assignee: nobody → general
Component: JavaScript Console → DOM: Core
Product: Firefox → Core
QA Contact: javascript.console → ian
Version: unspecified → 1.8 Branch
(Reporter)

Comment 2

13 years ago
Created attachment 205944 [details]
Start "frameset.htm" then click on link "test functionality"
(Reporter)

Comment 3

13 years ago
Created attachment 205945 [details]
Start "frameset.htm" then click on link "test functionality"
(Reporter)

Updated

13 years ago
Attachment #205945 - Attachment description: frameset for testcase → Start "frameset.htm" then click on link "test functionality"

Comment 5

13 years ago
But why did this work in Mozilla 1.7.12 then, Bug 26179 looks to me like it has always been like that? Anyway, looks like a dupe...
(Reporter)

Comment 6

13 years ago
It differs also from Firefox 1.0.7. 

Comment 7

13 years ago
I get this with UL elements. 

Whitespace is counted

UL elements can only have LI elements. (non-whitespace) text nodes generate an anonymous LI element. Whitespace is ignored. However, although the whitespace is not rendered as a text node, javascript recognizes a text node, so although it seems ignored, it really isn't. This is the problem.

Now if the WS is recognized as a node (as in the current build), then the rendering should also recognize that text node and render accordingly. In the case of the text in an UL, that would mean creating an LI element. This is of course not acceptable to expect developers to eliminate all ws between tags. (impractical example)

<ul><li>
     This is an li element.
    </li
    ><li>
     Number 2...
    </li
></ul>

VS. 

<ul> 
    <!-- create an anonymous LI 1 by using whitespace. -->
    <li> number 2. </li>
    <!-- create an LI 3 by using whitespace. -->
</ul>

There is an inconsistency between the DOM that is renderedand the DOM that javascript has access to. 

IMO, for any element which cannot have text nodes, whitespace should be ignored. I cannot think of a reason not to do it this way.

Comment 8

13 years ago
Created attachment 207019 [details]
ws recognized but not rendered.

Updated

13 years ago
Keywords: testcase
The whitespace _is_ rendered if you set  ul { white-space: pre }  in the CSS.

The whitespace between the <frame> elements is presumably a correction of an earlier error; it should always have been there.

To navigate the DOM without seeing text nodes I recommend using one of the DOM3 Traversal APIs.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 13 years ago
Keywords: testcase
Resolution: --- → INVALID

Updated

10 years ago
Component: DOM: Core → DOM: Core & HTML
QA Contact: ian → general
You need to log in before you can comment on or make changes to this bug.