Closed Bug 288644 Opened 20 years ago Closed 20 years ago

XHTML <textarea /> treated as <textarea> with no closing tag

Categories

(Core :: DOM: HTML Parser, defect)

Product:
Core
Component:
DOM: HTML Parser
Platform:
PowerPC
macOS
Type:
defect
Priority:
Not set
Severity:
minor

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: smagoun, Unassigned)

Details

Attachments

(1 file)

Testcase
338 bytes, text/xml
Details 
User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en) AppleWebKit/125.5.6 (KHTML, like Gecko) Safari/125.12
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

Mozilla + Firefox don't understand the <textarea /> tag in the following XHTML (which is valid XHTML 
1.0 Strict according to the W3C validator). It's interpreted as <textarea> with no closing tag, so 
everything following the tag is displayed inside the textarea as if it were the value of the textarea.

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head><title>foo</title></head>
<body>
<table>
  <tr>
    <td>
      <textarea rows="5" cols="40" />
    </td>
  </tr>
</table>
</body>
</html>


Reproducible: Always

Steps to Reproduce:
1. Display the XHTML in Mozilla or Firefox
2.
3.
Actual Results:  
All of the HTML following the <textarea /> is inserted into the textarea, instead of being treated as 
markup.

Expected Results:  
I expected <textarea /> to create an empty textarea

This is the same as bug 171462, which I tried to reopen but didn't have permission. The workaround is 
to use <textarea></textarea>.
If you know this is the same as bug 171462 -which is invalid, so this one is
also-  then why file a bug on this?
Because that's what Boris wants, as explained at the end of comment #2 in that bug:

"If this is XHTML being served as text/xml or some other XML type, please reopen
the bug; in that case we have a problem"

I ran into the problem using XHTML and was unabled to reopen 171462 - hence this new bug. Perhaps 
I should have said "this is very similar to bug 171462." Sorry for the confusion.
Attached file Testcase — 
Ah, ok. Sorry, I didn't read that part.
But it seems to work fine for me, using current trunk build, not?
Hmm, the attachment renders correctly when served from Bugzilla. Mozilla gets the test case right 
when opening the document from a file URL if the extension is anything but .html (.xhtml, .xml, .foo, 
etc). If the extension is .html and it's opened from a file URL, Mozilla gets it wrong. Naturally my test 
file had the .html extension. So it seems the DOCTYPE and <?xml?> declaration are ignored if the 
extension is .html (for file URLs) or the server reports content-type is text/html (for served content). If 
the extension or content-type is unknown, Mozilla pays at least some attention to the DOCTYPE and/or 
<?xml?> declaration. Rather annoying, but I guess understandable.

Given that, and the fact our server is incorrectly serving up some content as text/html after all (arrgh!), 
I suppose this is a violation of the XHTML spec's Appendix C.3 and therefore not a bug. Sorry for the 
noise.
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: