324018 - Textarea renders encoded entities & (ampersand) as translated characters

Status: RESOLVED DUPLICATE of bug 169762

(Core :: DOM: HTML Parser, defect)

Description

[Javier Valderrama]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8) Gecko/20051111 Firefox/1.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8) Gecko/20051111 Firefox/1.5

When a "character name" as &amp;[encoded apmersand] is "returned" from a database , even if it's correct on the page source the <textarea> renders it as a translated character, cousing several problems when an editor need to copy/paste html contents on Web based content managers. It's a critical problem when creating W3C compliant contents, mostly when creating dynamic web sites.



Reproducible: Always

Steps to Reproduce:
1.<textarea>
2.<a href="http://www.controls.it/products.php?code=44&amp;page=Geometrical_properties&amp;product=19&amp;prod_name=ASTM_Test_sieves">&middot; &nbsp; blabla</a>
3.</textarea>

Actual Results:  
"&amp;amp;" now is rendered as &
"&amp;middot;" now is rendered as ·
"&amp;nbsp;" now is rendered as white space

All encoded special characters [entity name] will be interpreted 

Expected Results:  
A <textarea> should render it's value "as is"; as it does on previous versions.

Comment 1

[Uriah Narmed]

Textareas can contain only #PCDATA -- parsed character data. HTML entities are parsed and displayed as the characters they represent. In #PCDATA, & literals must be HTML entities, as they are reserved characters.

If you want & in a textarea, you have to "double-escape" it in the source code as &. Yes, this is cross-browser compatible, and yes, the correct representation will be submitted from the form.

Comment 2

[Blake Kaplan (:mrbkap) (inactive)]

I don't see the behavior described in comment 0. Javier, can you attach a small testcase showing what you mean to this bug?

Comment 3

[Javier Valderrama]

Attachment: html page with 2 text area 1 with the code to copy 2 to paste content

Comment 4

[Javier Valderrama]

(In reply to comment #1 and #2) Gentle Uriah and Balke
in previous version Firefox 1.0.9 the double escaper was neccesary for <input type="text"> but not for <textarea>, content was shown as is, is not a big problem if you know it happens so I can write a simple php function to make my job but if you don't know anything about this change may a lot of developers will have undesiderable results.

Anyway, everytime you copy a double escaper string the copyed string is iterpreted again, so instead of having double escaped string when you paste you'll obtain a simple escaped string.

Another thing that I note is that since I install firefox 1.5 also I.E changes ....maybe because Mozzilla core is shared?

Comment 5

[Uriah Narmed]

The behavior has changed since Firefox 1.0.x, but only for <textarea> values that aren't properly escaped. When <, >, and & are represented as HTML entities there is no difference in behavior. (Your example would be changed to "<textarea>&lt;span&gt; [...]".)

The difference between 1.0.x and 1.5 is probably due to the checkin from bug 88952.

This bug is probably a dupe of 169762 or 109781.

Comment 6

[Javier Valderrama]

(In reply to comment #5)
Great, tnx Uriah for your interest and fast answers.

by the way.

Does Firefox 1.5 installer modifies to the I.E. Mozilla core? because the behaviour changes for IE too since I install FF 1.5

Comment 7

[Blake Kaplan (:mrbkap) (inactive)]

For the record: this sounds like the opposite of bug 154882. It is a duplicate of bug 169762. Thanks Uriah.

*** This bug has been marked as a duplicate of 169762 ***