227358 - textarea parsing: <? causes </textarea> to not be recognized

Status: RESOLVED FIXED

(Core :: DOM: HTML Parser, defect)

Description

[Joerg Napp]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de-AT; rv:1.5) Gecko/20031007
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-AT; rv:1.5) Gecko/20031007

In the following snippet, the closing </textarea> is not recognized. 

    foo 
    <textarea>
    <?  
    </textarea>
    bar

Reproducible: Always

Steps to Reproduce:
put the snippet above in a HTML page and view in Mozilla.

Actual Results:  
You see the </textarea> bar displaying _inside_ the textarea. 

Expected Results:  
Compare to IE which recognizes the </textarea>, so the <? should be displayed
inside the textarea, bar outside it.

First, I know that the snippet does not validate.

It happens in the constellation above. When you add _any_ closing angle bracket,
the error does not appear. 
    <textarea> <?  > </textarea>
renders correctly as well as 
    <textarea> <?  <a> </textarea>
does. 

Apperantly, it happens only with the question mark: 
    <textarea> <a  </textarea>
renders correctly.

Comment 1

[Anne (:annevk)]

> Compare to IE which recognizes the </textarea>, so the <? should be displayed
> inside the textarea, bar outside it.

:-) Mozilla != IE, but I think you are right, Mozilla should support this.

If this is important to you, or your company. Use:

"&lt;?"

Which will work correctly in every browser that exists and is used today.

Comment 2

[Joerg Napp]

> :-) Mozilla != IE
That's why I use Mozilla :-)

> If this is important to you, or your company. Use:
> 
> "<?"
> 
> Which will work correctly in every browser that exists and is used today.

Agreed that the sample code is not valid; I just found this issue using a forum
that doesn't do this translation. 
Anyway, I regard it as a bug by the circumstances -- wy is <? a problem, but
<foo is not? Why is <? a problem and <? <foo> is not? That is what looks strange.

Jörg

Comment 3

[Malcolm Rowe]

INVALID. The document you've supplied isn't valid HTML.

The content model for <textarea> is #PCDATA (parsed character data), which 
means that the parser must be involved (as opposed to #CDATA, where the parser 
can just skip ahead to </textarea>).

<? is the start of an SGML processing instruction, so I suspect the parser is 
getting confused.  But, just to reiterate, the document isn't valid anyway. 
Characters in #PCDATA sections that might be confused with markup (< and &, at 
a minimum) must be escaped as entity references.

Comment 4

[Malcolm Rowe]

(mid air collision: I see you know the document isn't valid).

Comment 5

[Anne (:annevk)]

I totally agree closing such bugs, but we need this for compat mode I believe.
Not everyone knows that HTML is a standard with rules ;-)

In any case this is not INVALID. It could be a DUPLICATE though.

Comment 6

[Christopher Hoess (gone)]

over to Parser

Comment 7

[Malcolm Rowe]

Fair enough, but the parser's a delicate beast, and we really don't want to be 
adding more exceptions to it if at all possible. Just how many sites depend on 
this? (of course, any site that does is probably open to trivial cross-site 
scripting attacks, but that's not relevant here).

Comment 8

[Boris Zbarsky [:bzbarsky]]

This is probably a wontfix, but choess may know more...

Comment 9

[Hixie (not reading bugmail)]

See also bug 105937, bug 154882, bug 64799 (or, search for "textarea parsing:" 
in the summary line).

Comment 10

[Anne (:annevk)]

Attachment: test case

Comment 11

[Blake Kaplan (:mrbkap) (inactive)]

FIXED by checkin to bug 88952

Comment 12

[Martijn Wargers (dead)]

*** Bug 277050 has been marked as a duplicate of this bug. ***

Comment 13

[L. H.]

*** Bug 288820 has been marked as a duplicate of this bug. ***

Comment 14

[Mike Connor [:mconnor]]

*** Bug 288820 has been marked as a duplicate of this bug. ***

Comment 15

[Uri Bernstein]

*** Bug 305071 has been marked as a duplicate of this bug. ***