Closed
Bug 17026
Opened 26 years ago
Closed 26 years ago
DOM is unable to see objects
Categories
(Core :: DOM: Core & HTML, defect, P3)
Tracking
()
VERIFIED
INVALID
People
(Reporter: jcarpenter0524, Assigned: vidur)
Details
Attachments
(5 files)
Overview Description:
In the attached test case DOM is unable to see the [object Text]
Note: If you run this test in viewer, you will see the correct result
initially, however if you then reload viewer you will see the "null" result
instead.
It doesn't seem to matter what object I use here, text was just simplest.
Steps to Reproduce:
- Run attached test case in Apprunner
- Note result is "null"
Actual Results:
null
Expected Results:
[object Text]
Build Date & Platform Bug Found:
Win98 1999102111
Additional Builds and Platforms Tested On:
MacPPC, Linux
Additional Information:
|
Reporter | |
Updated•26 years ago
|
QA Contact: gerardok → janc
|
|
Reporter | |
Comment 1•26 years ago
|
||
|
|
Reporter | |
Comment 2•26 years ago
|
||
|
|
Reporter | |
Comment 3•26 years ago
|
||
I don't know why the attachments aren't working, here's the source:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>test</TITLE>
<SCRIPT TYPE="text/javascript" SRC="../testlib.js"></SCRIPT>
</HEAD>
<BODY>
Hi Mom.
<SCRIPT TYPE="text/javascript">
var oList=document.firstChild.childNodes[1].childNodes[0];
document.write(oList);
</SCRIPT>
</BODY>
</HTML>
|
|
Reporter | |
Updated•26 years ago
|
Severity: blocker → major
|
|
Reporter | |
Comment 4•26 years ago
|
||
Lowering Severity from blocker to major.
|
|
Reporter | |
Updated•26 years ago
|
Summary: [BLOCKER]DOM is unable to see objects → DOM is unable to see objects
|
|
||
Comment 5•26 years ago
|
||
|
|
||
Comment 6•26 years ago
|
||
Weird. The attached testcase shows the following output in Linux x86 build
1999102608 on Red Hat 6.0:
----------
Whatever.
Name 0: {HEAD}
Value 0: {}
Name 1: {#text}
Value 1: {
}
Name 2: {BODY}
Value 2: {}
----------
There seems to be a "phantom" text node between the BODY and HEAD elements. So,
in janc's example code, doing:
<SCRIPT TYPE="text/javascript">
var oList=document.firstChild.childNodes[2].childNodes[0];
// ......................................^ note 2 instead of 1
document.write(oList);
</SCRIPT>
would find the "Hi Mom." text node.
|
|
Assignee | |
Updated•26 years ago
|
Status: NEW → RESOLVED
Closed: 26 years ago
Resolution: --- → INVALID
|
|
Assignee | |
Comment 7•26 years ago
|
||
I'm not sure I see the problem here. The TextNode visible at
document.firstChild.childNodes[1] is the whitespace between the HEAD and the
BODY. The DOM spec allows such whitespace to be preserved, even if it isn't
significant. I'm surprised at Jan's comment that she got inconsistent results.
The result were always the same for me - the null of result of looking at the
childNodes of the whitespace Text node.
Marking INVALID - it works as I would expect. As chadh mentions, the BODY
element (if that's what you're looking for) is document.firstChild.childNodes[2]
(or, better yet, document.body).
|
|
Reporter | |
Updated•26 years ago
|
Status: RESOLVED → REOPENED
|
|
Reporter | |
Updated•26 years ago
|
Resolution: INVALID → ---
|
|
Reporter | |
Comment 8•26 years ago
|
||
The problem is that I should indeed find the "Hi Mom" text node, but don't.
I expect to see "[text node]"
But instead I was seeing "null".
In today's build (1999102808) the document.write statement produces nothing at
all.
I grabbed a random old build (1999090310), ran this test, and I do see the
"[text node]" as expected.
Is this a bug or has something been changed that makes my test invalid?
|
|
||
Comment 9•26 years ago
|
||
janc, I'm guessing older builds didn't preserve the whitespace between HEAD and
BODY as a child node of HTML, so document.firstChild.childNodes[1] was the BODY
element in your testcase. In more recent builds, [1] is the whitespace text
node, and document.firstChild.childNodes[2] is the BODY (in your testcase).
As vidur suggests, the test should probably use document.body rather than
document.firstChild.childNodes[n] to refer to the BODY element.
|
|
Reporter | |
Updated•26 years ago
|
Severity: major → normal
|
|
Reporter | |
Comment 10•26 years ago
|
||
chadh, I agree that document.body would be a better way to go, however,
shouldn't document.firstChild.childNodes[2].childNodes[1] work?
I've tried this and also just taking my original code and removing all
whitespace so that the code is all one line. Nothing is working.
|
|
||
Comment 11•26 years ago
|
||
Hmm ... that should be:
document.firstChild.childNodes[2].childNodes[0]
.............................................^ 0, not 1
which displays:
Hi Mom. [object Text]
in Linux x86 build 1999110108. I'll attach the modified testcase.
|
|
||
Comment 12•26 years ago
|
||
|
|
||
Comment 13•26 years ago
|
||
Interesting. Even when there's no whitespace between HEAD and BODY, e.g.
</head><body>
there is *still* a Text node being generated. The following HTML:
====================
<html>
<head>
<title>Bug 17026 - no WS between HEAD and BODY</title>
</head><body>
(No whitespace between HEAD and BODY elements.)
<pre>
<script type="text/javascript">
var fc = document.firstChild;
for (var i = 0; i < 3; i++) {
document.write("Name " + i + ": {" + fc.childNodes[i].nodeName + "}\n");
document.write("Value " + i + ": {" + fc.childNodes[i].nodeValue + "}\n");
}
</script>
</pre>
</body>
</html>
====================
produces this:
(No whitespace between HEAD and BODY elements.)
Name 0: {HEAD}
Value 0: {}
Name 1: {#text}
Value 1: {
}
Name 2: {BODY}
Value 2: {}
The DOM spec allows whitespace to be preserved, but this seems to be a case of
inserting whitespace where there is none. Bug?
|
|
||
Comment 14•26 years ago
|
||
|
|
Reporter | |
Updated•26 years ago
|
Status: REOPENED → RESOLVED
Closed: 26 years ago → 26 years ago
Resolution: --- → INVALID
|
|
Reporter | |
Comment 15•26 years ago
|
||
Gak! I swear I tried that yesterday and it didn't work! Today it does (much to
my relief, and I'm sure to yours as well.) Thank you.
Marking invalid and closing bug.
Status: RESOLVED → VERIFIED
|
||
Updated•6 years ago
|
Component: DOM → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•