198217 - The XML in the form is rendered wrong.

Status: RESOLVED FIXED

(Core :: DOM: HTML Parser, defect)

Description

[atr]

User-Agent:       Opera/7.03 (Windows NT 5.1; U)  [en]
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3) Gecko/20030312

The XML in the form has elements in the form <MSH.1>text</MSH.1> but when 
rendered and when submitted in the post it becomes <MSH.1>text</MSH>, which of 
course is a bad XML.


Reproducible: Always

Steps to Reproduce:
1. Just load the attached .html file and see for yourself.



Actual Results:  
The XML in the TEXTAREA is wrong [<MSH.1>|</MSH>]. It's correct in the source 
when viewed in a external editor *and* in the Mozilla source viewer.


Expected Results:  
It should have displayed <MSH.1>|</MSH.1>


I made it critical because we lose data and thus cannot use Mozilla at all. 
Since there is no workaround, this feels urgent.

Comment 1

[atr]

Attachment: An html page where this problem occurs.

Just open and you'll see

Comment 2

[atr]

This also happens in Mozilla 1.2, 1.3b and 1.3 under Linux.

Comment 3

[Christopher Hoess (gone)]

This isn't actually valid, but we have a bug on handling this a little better.
The problem is that you're not escaping the XML inside the textarea: when you
"view source" on the HTML page containing the XML, you should see

<textarea>
&lt;!DOCTYPE...
&lt;tag>some data&lt;/tag>
</textarea>

where "<" has been escaped as "&lt;" and "&" has been escaped as "&amp;".

Your page has

<textarea>
<!DOCTYPE...
<tag>some data</tag>
</textarea>

which forces the HTML parser to try and parse your HTML. Escaping the XML in the
source will make the contents of the textarea display exactly the same, but it
will also be valid and work in Mozilla.

Comment 4

[atr]

Mr Hoess,

I understand what you are saying. However, the page attached works as-in under
Opera and (aaaargh!) IE. What puzzled us was why did it work when we did not
have any of those <xxx.xxx> tags and only caused problems with those.

We never had to escape the XML inside TEXTAREAs before and have hundreds of
pages we have to change to implement this. As you could imagine we'd rather not
have to do this. 

Why is it that in your snippets, you escape the < and not the >. Could you point
me to a page where the specs on this are located? I need to convince some people
if I want to make those changes that we are off-spec.

Comment 5

[Heikki Toivonen (remove -bugzilla when emailing directly)]

I see this too. I think our parser might get confused by the "." in the tag
name. Still, I think the correct way is to escape "<" and "&".

atr: it is not necessary to escape ">" because it does not start any special
markup. Of course you may want to do it anyway, for consistency.

Comment 6

[Boris Zbarsky [:bzbarsky]]

This is still a duplicate... We have other (much older) bugs on this same issue.
 As long as we parse what's inside <textarea>, this will crop up (it shows up in
a variety of ways, not just in dropping the ".1" in </foo.1>).

Comment 7

[atr]

Mr Zbarsky,

What is the bug number for the duplicated bug? Maybe I should have found it but
obviously, I didn't. I'd like to see the conversation on that.

Comment 8

[atr]

Mr Zbarsky,

What is the bug number for the duplicated bug? Maybe I should have found it but
obviously, I didn't. I'd like to see the conversation on that.

Comment 9

[Christopher Hoess (gone)]

atr: wrt specifications, see
<URL:http://www.w3.org/TR/html401/charset.html#h-5.3.2>, the text beginning
"Four character entity references..." This can be confirmed by
<URL:http://validator.w3.org/>, comparing a document with and without escaping.
There may also be security issues here, as well; I don't know what your data
flow from these forms looks like, but consider the consequences of someone
maliciously or accidentally entering "</textarea>", "</body>", or "</html>" into
the XML editing form.

Comment 10

[atr]

So where does this report go then? Is is still OPEN or is it considered not a
bug and therefore closed?

I appreciate all the responses.

Comment 11

[Christopher Hoess (gone)]

This is similar to bug 99467 and bug 64799, but not exactly. Harish, should we
create a meta-bug for compatibility parsing of unescaped markup in textareas?

Comment 12

[Boris Zbarsky [:bzbarsky]]

Fixed by patch in bug 64799