TEXTAREA bug in Mozilla?

[Jennifer Palonus]

I'm getting weird behavior in Firefox 2.0.0.9 when I try to query the
textContent of a textarea.

In this example, when I hit the [Test] button, the alert should show
me the text that's currently in the textarea. IE does this fine, but
Firefox always shows me the initial text, even if I type something
else into the textarea.

============================
<script>
if (window.createPopup)
{g_sBrowserType = "IE";
}
else
{g_sBrowserType = "Mozilla";
}


function onClickTest ()
{
var oEditor = document.getElementById("taEditor");
var sText = g_sBrowserType=="IE" ? oEditor.innerText :
oEditor.textContent;

alert (sText);
}
</script>


<b>Source text</b><br>
<form name="frmTest">
<textarea id="taEditor" cols="80" rows="20">My initial text</textarea>

<p><button type="button" onclick="onClickTest()">Test</button>
============================

Graphical Dynamics, Inc
http://www.graphicaldynamics.com

 

[Thomas 'PointedEars' Lahn]

I'm getting weird behavior in Firefox 2.0.0.9 when I try to query the
textContent of a textarea.

It is not weird at all if you know what you are doing.

In this example, when I hit the [Test] button, the alert should show
me the text that's currently in the textarea. IE does this fine, but
Firefox always shows me the initial text, even if I type something
else into the textarea.

Firefox is correct, IE is not. (Surprised?)

The `textContent' attribute of the Node interface is defined to be a
concatenation of all text nodes of the element and its descendants. These
(the underlying markup) are not supposed to change just because you changed
the control's value:

http://www.w3.org/TR/DOM-Level-3-Core/core.html#Node3-textContent

Use the `value' attribute of the HTMLTextAreaElement interface to retrieve
the actual value of the control instead:

http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-24874179


PointedEars

 

[RobG]

I'm getting weird behavior in Firefox 2.0.0.9 when I try to query the
textContent of a textarea.

In this example, when I hit the [Test] button, the alert should show
me the text that's currently in the textarea. IE does this fine, but
Firefox always shows me the initial text, even if I type something
else into the textarea.

============================
<script>
if (window.createPopup)
{g_sBrowserType = "IE";

If you wish to test for support for a particular feature, use a test
for that feature, not some other feature that may or may not be
related.

}
else
{g_sBrowserType = "Mozilla";
}

function onClickTest ()
{
var oEditor = document.getElementById("taEditor");
var sText = g_sBrowserType=="IE" ? oEditor.innerText :
oEditor.textContent;

var sText;
if (typeof oEditor.textContent == 'string') {
sText = oEditor.textContent;
} else if (typeof oEditor.innerText == 'string') {
sText = oEditor.innerText;
} else {
/* get text content some other way */
}


But as Thomas pointed out, you should be using the element's value
attribute.

 

[Jennifer Palonus]

I'm getting weird behavior in Firefox 2.0.0.9 when I try to query the
textContent of a textarea.

It is not weird at all if you know what you are doing.

In this example, when I hit the [Test] button, the alert should show
me the text that's currently in the textarea. IE does this fine, but
Firefox always shows me the initial text, even if I type something
else into the textarea.

Firefox is correct, IE is not. (Surprised?)

The `textContent' attribute of the Node interface is defined to be a
concatenation of all text nodes of the element and its descendants. These
(the underlying markup) are not supposed to change just because you changed
the control's value:

http://www.w3.org/TR/DOM-Level-3-Core/core.html#Node3-textContent

Use the `value' attribute of the HTMLTextAreaElement interface to retrieve
the actual value of the control instead:

http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-24874179


PointedEars

Whoa, so it is!

But, I guess this means that all those examples of how to simulate
..innerText in Mozilla by using .textContent are wrong, at least WRT
HTMLTextAreaElements.

Ironically, though, in my application I also have a single line <input
type="text" value="initial text"> element. For this I can get the
current text using .textContent just fine in Mozilla.

Thanks,
Jenny
Graphical Dynamics, Inc
http://www.graphicaldynamics.com

 

[RobG]

It is not weird at all if you know what you are doing.

In this example, when I hit the [Test] button, the alert should show
me the text that's currently in the textarea. IE does this fine, but
Firefox always shows me the initial text, even if I type something
else into the textarea.

Firefox is correct, IE is not. (Surprised?)

The `textContent' attribute of the Node interface is defined to be a
concatenation of all text nodes of the element and its descendants. These
(the underlying markup) are not supposed to change just because you changed
the control's value:

Use the `value' attribute of the HTMLTextAreaElement interface to retrieve
the actual value of the control instead:

PointedEars

Whoa, so it is!

But, I guess this means that all those examples of how to simulate
.innerText in Mozilla by using .textContent are wrong, at least WRT
HTMLTextAreaElements.

Ironically, though, in my application I also have a single line <input
type="text" value="initial text"> element. For this I can get the
current text using .textContent just fine in Mozilla.

I'd like to see the code for that, try the following:


<input id="inp0" type="text" value="initial text">

<input type="button" value="Show value"
onclick="alert(document.getElementById('inp0').value);">

<input type="button" value="Show innerText"
onclick="alert(document.getElementById('inp0').innerText);">

<input type="button" value="Show textContent"
onclick="alert(document.getElementById('inp0').textContent);">


Since input elements can't have any content, both IE and FireFox show
empty string or undefined (as appropriate) in the above, which is the
expected behaviour.

 

[Jennifer Palonus]

On Dec 3, 12:34 pm, Jennifer Palonus <jpalo...@graph-intron-ical-
intron-dy-intron-namics.com> wrote:

I'd like to see the code for that, try the following:


<input id="inp0" type="text" value="initial text">

<input type="button" value="Show value"
onclick="alert(document.getElementById('inp0').value);">

<input type="button" value="Show innerText"
onclick="alert(document.getElementById('inp0').innerText);">

<input type="button" value="Show textContent"
onclick="alert(document.getElementById('inp0').textContent);">


Since input elements can't have any content, both IE and FireFox show
empty string or undefined (as appropriate) in the above, which is the
expected behaviour.

Oops, you're right, I was getting the .value for my text field.

OK, that's making sense now.
Graphical Dynamics, Inc
http://www.graphicaldynamics.com

 

[Thomas 'PointedEars' Lahn]

Thomas 'PointedEars' Lahn said the following on 12/2/2007 8:37 PM:

And reading the MSDN article on innerText might give you a little
insight into what you are doing. That and giving it a little thought
beyond wanting to simply say "IE is wrong".

I stand corrected. Sorry for the confusion, I did not read the OP's source
code carefully enough.

OP: IE is _not_ wrong here as with your supposedly flawed browser switch
you are accessing the proprietary _`innerText'_ property with IE, but the
standardized `textContent' property with non-IE. Those two properties are
_not_ equivalent. (In fact, it would seem IE does not support `textContent'
at all.)


PointedEars

 

[Thomas 'PointedEars' Lahn]

Thomas 'PointedEars' Lahn said the following on 12/3/2007 2:49 PM:

An argument can even be made that Firefox is dead wrong with this one.

But not a solid one.

According to the URL you posted:

This attribute returns the text content of this node and its descendants.
Exactly.

If you put this in an HTML document, then open it with Firefox and use
the DOM Inpector to look at it, it shows a textNode under the textarea.

As it should. With

<textarea ...>foo</textarea>

you have a TEXTAREA element node that has a child text node with the value
"foo".

That means that FF is reading the raw HTML instead of the actual
contents of that text node.

As it should. What you call "raw HTML", however, is the markup which makes
up the document tree that remains unchanged here. Which is what the DOM
Inspector shows in the left pane if you set it in "DOM Nodes" mode, and in
the right pane, if you inspect the selected object as a "DOM Node".

- TEXTAREA
|
----#text

If it isn't reading the current content of the node, then isn't it
getting it wrong?

No, it isn't. As I have said (and referred to the corresponding part of the
specifications), the current value of the control is _not_ equal to the node
value of the text node that is the child element of the TEXTAREA element,
where the latter is displayed by the DOM inspector in the left pane. Hence
there is a `value' attribute and property as well.

If you inspect the TEXTAREA node as a "JavaScript Object" again after you
changed the text in the control you will see that the `value' property of
the object changed. (The `defaultValue' property of the control object
yields a value that is equal to the value of the child text node; if the
element had no content [and so there was no text node], it is the empty string.)

Agreed. A better test would have been something like:

var sText = oEditor.textContent?oEditor.textContentEditor.innerText;

No, as these two properties are _not_ equivalent, one should forego the
`innerText' property access and access the `value' property instead; the
latter is both standardized and backwards compatible to DOM Level 0.


PointedEars

 

[Thomas 'PointedEars' Lahn]

Thomas 'PointedEars' Lahn said the following on 12/3/2007 3:49 PM:

If you compare two elements: DIV and TEXTAREA, in the DOM Inspector, both
have a text node as the child element. If you read the textContent of
both, without altering either, it will give you what was in the raw HTML.
If you alter the contents of that div element using innerHTML, and then
read it back using textContent, you will get *what is currently there*.
The fact that one is a form element and one isn't shouldn't matter as far
as the behavior of what textContent reports.

Now, should it read the raw HTML - all of the time - or should it read
what is currently there - all of the time - or do you just accept that
textContent has some screwy criteria for what it returns?

Your problem is to make the distinction between controls and other elements.
A control is an object that has a value of itself, and it is also an
element that has a child text node which has a value of itself. A `div'
element is not implemented as a control; it cannot be altered by the user;
it only has child elements, not a value of itself.

I wasn't referring to this case in particular. I was referring to a test,
in general, for support of textContent or innerText instead of relying on
the window.createPopup trying to identify IE.

As a test for support, Rob's solution is better. Because, as described, the
value of the `textContent' property, albeit supported, can be the empty
string which would evaluate to `false' here.

[...] The only reason textContent ever came about was the lack of support
in non-IE browsers for innerText and the desire to have an equivalent
"standard" property for it. With regards to that, the W3C blew it on this
one.

That the W3C was going to implement `textNode' as a property equivalent to
`innerText' "to have a standards compliant alternative" is merely a figment
of your imagination, as therefore is your notion that they "blew on this one".


PointedEars

 

[Thomas 'PointedEars' Lahn]

Thomas 'PointedEars' Lahn said the following on 12/3/2007 4:28 PM:

That only goes to what I wrote. textContent has some screwy criteria for
what it returns.

Either you have never bothered to read and understood the specification
or that is an outright lie in order to troll a little again. It is well
defined what textContent is supposed to "return":

http://www.w3.org/TR/DOM-Level-3-Core/core.html#Node3-textContent

If you have trouble understanding that, try

http://developer.mozilla.org/en/docs/DOM:element.textContent

[...] The body element in designMode is not a control

Actually, for all intents and purposes, it is. But you are confusing things
here and probably you should read my posting again.

yet textContent reads what is there at the time you try to read it.

`designMode' is not part of any public specification. You can not expect
standardized interfaces to behave accordingly with proprietary features.

That said, I would assume that with an element in designMode on editing the
child text nodes are modified directly, in which case textContent for the
parent `body' element would yield exactly what it is supposed to yield.

var sText =
oEditor.textContent?oEditor.textContentEditor.innerText;
[...]
I wasn't referring to this case in particular. I was referring to a test,
in general, for support of textContent or innerText instead of relying on
the window.createPopup trying to identify IE.

As a test for support, Rob's solution is better. Because, as described, the
value of the `textContent' property, albeit supported, can be the empty
string which would evaluate to `false' here.

Very true. And I didn't say my code was the best, it was only better
than what was posted.

You would call that "whining", remember? I have not even accused you of
what you imply here I did.

[...] The only reason textContent ever came about was the lack of support
in non-IE browsers for innerText and the desire to have an equivalent
"standard" property for it. With regards to that, the W3C blew it on this
one.

That the W3C was going to implement `textNode' as a property equivalent to
`innerText' "to have a standards compliant alternative" is merely a figment
of your imagination, as therefore is your notion that they "blew on this one".

If you want to think that textContent wasn't a result of innerText, then
you keep believing that. The W3C is a joke.

Your argument, or rather the lack of it, is a joke, although not a very
funny one.


PointedEars

 

[Thomas 'PointedEars' Lahn]

Thomas 'PointedEars' Lahn said the following on 12/5/2007 7:03 PM:

Either you have never bothered to read and understood the specification
or that is an outright lie in order to troll a little again. It is well
defined what textContent is supposed to "return":

http://www.w3.org/TR/DOM-Level-3-Core/core.html#Node3-textContent

If you have trouble understanding that, try

http://developer.mozilla.org/en/docs/DOM:element.textContent

Neither of which deals with the issue I showed you. Yet both go to show
exactly what I said "What textContent returns depends on....".

[...] The body element in designMode is not a control

Actually, for all intents and purposes, it is. But you are confusing things
here and probably you should read my posting again.

By your own definition of what a control is, it is not a control.

"A control is an object that has a value of itself, and it is also an
element that has a child text node which has a value of itself."

And the body element does not satisfy your definition.

The `body' element, by default, is not a control. The proprietary extension
makes it (and other no-controls) to behave like one, but that does not mean
that it has to have both the aforementioned properties then. From A --> B
does not follow B --> A.

How can anybody be expected to understand what you write if you can't
even make up your own mind as to what you mean?

You know very well that I did not have proprietary features in mind when
posting that definition. Stop trolling and start discussing for a change.

So, Mozilla can't be expected to behave accordingly with it's own
specifications for textContent. Nice.

No, unsurprisingly you "misunderstand" again.


PointedEars