User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 I have a large table that contains textareas holding a bit of data. When I only have a few textareas inside the table, Mozilla displays the text with no problem. When I have many rows (say in excess of 50), Mozilla sometimes closes out the textarea when I print the "</textarea>" tag, and sometimes does not. On IE, there is no problem with the display. I would include code, but it is for an internal project, so I don't want to post our html here. Reproducible: Always Steps to Reproduce: 1. Write a small jsp page (or pick your language) to output many rows to a table with five columns. Write the data out to each row, with the correct number of <TD></TD> bracketed areas. In the final column, set up an inset textarea: i.e.: <TD><TEXTAREA>some data</TEXTAREA>. End the Row there. Continue for a large number of rows (over 50). Check the display in IE and Mozilla. Actual Results: This is roughly what my jsp page does here. The above steps should reproduce the problem. Expected Results: Uh, closed out the textareas and continued on to another row.

If you can attach a testcase that has internal data removed, that would be helpful -- I can't reproduce this with Linux trunk build 2004-01-15-07.

Attached please find a testcase that should reproduce the bug on all versions of mozilla. I would really like to see this issue cleared up, as it is a big problem for anyone that uses multiple textareas in a table.

So the problem is markup like this: <textarea> <foo bar="baz </textarea> Text you expect not to be in the textarea right? Note that what goes inside a textarea _is_ markup. Tags in there get parsed (so character entities work). The "</textarea>" gets parsed as part of the attribute named "baz" (since the close quote there is missing). Is there a reason you're dumping all those unescaped tags into the textarea? Simply escaping '<' and '>' as &gt; and &lt; would eliminate this problem for you.... Ian, chris, what do you think? In light of the discussion in bug 64799, I don't think we will ever have "support" for the sort of markup in this testcase....

Hm, true, I am dumping unexpected markup into the text area ... but it should still parse correctly until it finds the end textarea tag ... regardless of what the preceding contents are. That is the issue with this bug. So long as none of the markup inside the textarea is a closing </textarea> tag, it should render correctly. IMHO a textarea serves a function similar to a PRE tag .... allowing authors to display markup in the browser window, within the limits of not violating the enclosing delimiters. i.e.: <pre> Bold text is demarked by "<bold>bold text</bold>".</pre> Not: <pre> Preformatted text is demarked by: "</pre>Preformatted Text</pre>". The first "</pre>" typo closes out the first delimeter. Anyway, this is basic parsing 101 ... which I would hope the mozilla parser would function like ....

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

> but it should still parse correctly until it finds the end textarea tag It does parse correctly, and it never finds that tag. > IMHO a textarea serves a function similar to a PRE tag Unfortunately, that's not what the HTML spec says it does. In particular, character entities inside <pre> are NOT interpreted, whereas in a textarea they must be. Hence the text inside a <pre> is literal text, while the text inside a textarea must be tokenized as HTML. More precisely, <pre><foo></pre> is valid HTML while <textarea><foo></textarea> is not valid HTML and the browser's behavior is undefined (read that as: do whatever makes the most sense). In this case, we plan to do whatever breaks the least sites while being least complicated; since in the last 4 years there are very few bug reports I've run into (less than 5) that are caused by our error-recovery behavior, I am hesitant to introduce yet another complicated tokenization codepath to handle this particular instance of invalid HTML.

Hm, true, I am dumping unexpected markup into the text area ... but it should still parse correctly until it finds the end textarea tag ... regardless of what the preceding contents are. That is the issue with this bug. So long as none of the markup inside the textarea is a closing </textarea> tag, it should render correctly. IMHO a textarea serves a function similar to a PRE tag .... allowing authors to display markup in the browser window, within the limits of not violating the enclosing delimiters. i.e.: <pre> Bold text is demarked by "<bold>bold text</bold>".</pre> Not: <pre> Preformatted text is demarked by: "</pre>Preformatted Text</pre>". The first "</pre>" typo closes out the first delimeter. Anyway, this is basic parsing 101 ... which I would hope the mozilla parser would function like .... Okay, you can close out if you'd like. I see your point as regards to the texstrea versus a pre element. I should be able to get the same effect by means of a scrollable div tag with a pre element set.

bz, you're on crack, <pre> is not a CDATA block, it's just a normal element. ;-) Maybe you meant <script> or something. Anyway, as I've said before, I think the ideal thing for us to do is treat <textarea> contents as (error-handling-)RCDATA, and only let a </textarea> end tag close it. This means only parsing entities, and nothing else. Incidentally, this particular case shouldn't be giving us trouble anyway. <foo</foo> ...is perfectly valid markup. (The STAGC delimiter, ">", is optional when the next token is a STAGO, "<", or ETAGO, "</", since in HTML the SHORTTAG feature is enabled.) We support this: http://www.hixie.ch/tests/adhoc/html/parsing/shorttag/tagc-omission/001.html http://www.hixie.ch/tests/adhoc/html/parsing/shorttag/tagc-omission/002.html ...although note the way that View Source mangles those files.

Oh, right. I was thinking <xmp>... In that case, the comparison is actually valid, and <pre> would also not close on markup like that page is dumping into the textarea. As for doing RCDATA, that would be the "yet another complicated tokenization codepath" route, Ian. Too much code, too little benefit, too little testing to shake out the inevitable bugs.

Oh, I agree (and it's non-standard anyway, so it's hardly worth it). Would be nice to have a real testcase (i.e. something much less than 1kb, with no extraneous markup) to see what exactly is causing this to fail in this particular case though.

Interestingly, if I add whitespace before the "</textarea" (but inside the quotes) the parsing changes. That seems odd; I'll look into it.

works in opera :-)

Changing status from unconfirmed, as we clearly have a testcase here which still demonstrates this quirk in build 2004052709. I'm not sure this can be classified as a major issue though, if the workaround is to escape the chevrons and the behaviour appears to agree with the spec (minus quirks)...?

True, its not a major issue, but it forces my clients to use IE -- which is something I would like to avoid. I know that you guys don't want MSFT to be better in rendering! ;-) Anyway, it would be nice to see a fix for this at some point.

The real fix for this is on the server side. That content is invalid HTML and should be escaped.

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

FIXED by checkin to bug 88952