162653 - <textarea/> doesn't work correctly (XHTML served as text/html using XML-style self-closing tags)

Status: VERIFIED INVALID

(Core :: DOM: HTML Parser, defect)

Description

[David Corbin]

I have an XHTML Transitional document (don't know if that actually matters). 
When I put in a textarea as an empty tag (<textarea/>), I get differrent
behavior than if I use <textarea></textarea>.  The "different behavior" was the
rest of my XHTML document text showing up IN the textarea, and not on the page.
  As my XHTML is generated from a server-side DOM, working around this bug is
very hard.

Comment 1

[Christopher Aillon (sabbatical, not receiving bugmail)]

Could you at least give us a URL or upload a page so we can see this ourselves?

Comment 2

[Boris Zbarsky [:bzbarsky]]

You are serving your XHTML as text/html.  According to the XHTML 1.0
specification, you may only do this if your XHTML follows the Appendix C
compatibility guidelines.  The use of <textarea /> instead of
<textarea></textarea> violates section C.3 of appendix C.

If you want us to parse your XHTML as XML, please give it the correct MIME type
(text/xml or application/xhtml+xml).

Comment 3

[David Corbin]

Attachment: Example of xhtml document with "failure"

Comment 4

[David Corbin]

When I set the content type as "xml", the content is displayed, but it contains
no formatteing.  I've attempted to set the content-type to "xhtml+xml", but I've
had some problems caused by our framework not accepting that.  I'll keep working
on that and see if that improves things.

I'll admit to not knowing the details of the spec, but it seems to me with the
XML declaration and the document DTD specified, it should be clear that it is
xhtml and not html.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 95252 [details]
Example of xhtml document with "failure"

fixing bogus MIME type

Comment 6

[Boris Zbarsky [:bzbarsky]]

You need to put an "xmlns" attribute whose value is the XHTML namespace on your
root element... see the examples in the XHTML specification.  Then formatting
will happen like you want.

We _could_ content-sniff the document, but that would be just like sniffing
text/plain documents to see whether we think they are HTML.  Instead, we follow
the HTTP standard and use the content-type given by the server.  text/html is
parsed with the HTML parser, not the XML parser.

Comment 7

[Wesha]

v.

Comment 8

[Bill Mason]

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

Comment 9

[José Jeria]

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

Comment 10

[Elmar Ludwig]

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

Comment 27

[dampjam]

According to the spec you should be content sniffing for the doctype/xmlns tags if it is html/plain...

I have both set and my bug symptoms are still being exhibited... please see closing img tags post html-render as well as closing anchor tags with a /

Comment 28

[Boris Zbarsky [:bzbarsky]]

According to the XHTML 1.0 spec, XHTML may be sent as text/html only if it complies with Appendix C of the XHTML specification.  Any document that uses "<textarea/>" does not comply with Appendix C.

Comment 29

[dampjam]

but <textarea /> is as well as <img src="blah.jpg" alt="blah blah" /> is... Appendix C specifically specifies that if you include a space before the trailing / you may minimize tags (and are forced to for img tags).

Thus, firefox removing the trailing / in post-render is in violation of the entire XHTML 1.0 spec.

Comment 30

[Boris Zbarsky [:bzbarsky]]

> but <textarea /> is

No, because per appendix C you may not minimize tags that don't have an empty content model.

The <img> case is indeed per appendix C, and we handle it per the spec.  I'm really not sure what problem you're having with <img> and why you think it's a Gecko bug.  The issue described in bug 410303 seems to be a bug in the validator...

Comment 46

[Manu]

This bug has been here since 2002, can anyone solve it? It's not that big, but can be annoying...

Comment 47

[Dão Gottwald [:dao]]

The reported behavior is not a bug.

Comment 53

[Intermittent Failures Robot]

1 failures in 3349 pushes (0.0 failures/push) were associated with this bug in the last 7 days.

Repository breakdown:

• mozilla-central: 1

Platform and build breakdown:

• android-em-7-0-x86_64-qr: 1
  • debug: 1

For more details, see:
https://treeherder.mozilla.org/intermittent-failures/bugdetails?bug=162653&startday=2023-12-18&endday=2023-12-24&tree=all