Closed
Bug 1403284
Opened 8 years ago
Closed 8 years ago
XHTML documents are not rendered correctly
Categories
(Core :: DOM: HTML Parser, defect)
Tracking
()
RESOLVED
INVALID
People
(Reporter: marius.spix, Unassigned)
Details
Attachments
(3 files)
screenshot.png
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:53.0) Gecko/20100101 Firefox/53.0
Build ID: 20170716190630
Steps to reproduce:
Build identifier: Mozilla/5.0 (X11; Linux x86_64; rv:53.0) Gecko/20100101 Firefox/53.0
Given is the following document:
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd" [
<!ENTITY foo "bar">]>
<html
xmlns="http://www.w3.org/1999/xhtml">
<head>
<title/>
</head>
<body>
<p>&foo;</p>
</body>
</html>
Actual results:
A page with the title "</head> <body> <p>&foo;</p> <body> </html>" and the content "]>" is rendered.
Expected results:
A page with an empty title and the content "bar" should appear.
|
Reporter | |
Comment 1•8 years ago
|
||
Please remember to remove the indentation of 4 spaces before testing.
|
||
Updated•8 years ago
|
Component: Untriaged → HTML: Parser
Product: Firefox → Core
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:55.0) Gecko/20100101 Firefox/55.0
testcase works as expected for me
|
||
Comment 4•8 years ago
|
||
I confirmed attachment 8912889 [details] works as expected for me on nightly 58 on OSX and Win10. If I changed the mime type to html, then I saw what Reporter saw.
Dear Reporter,
Would you mind checking the mime type setup? Thanks you.
Flags: needinfo?(marius.spix)
|
|
Reporter | |
Comment 5•8 years ago
|
||
|
|
Reporter | |
Comment 6•8 years ago
|
||
Flags: needinfo?(marius.spix)
|
|
Reporter | |
Comment 7•8 years ago
|
||
It seems to work fine, when you access the file via HTTP. However the file is falsely detected as text/html when accessed via file system. So I think the MIME type detection is broken?
If you test locally .html files are handled as HTML.
.xml or .xhtml or .xht files are handled as XML/XHTML.
Nothing wrong here, as far as I can tell.
Closing this bug, feel free to comment and reopen if I misunderstand the issue or if there are different results in other browsers.
Status: UNCONFIRMED → RESOLVED
Closed: 8 years ago
Resolution: --- → INVALID
|
|
Reporter | |
Comment 9•8 years ago
|
||
Thank you. Renaming to .xhtml fixed that issue.
However, RFC 3236 clearly states
There are three known file extensions that are currently in use
for XHTML 1.0; ".xht", ".xhtml", and ".html".
So I don’t consider this bug as invalid.
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
|
|
||
Comment 10•8 years ago
|
||
(In reply to marius.spix from comment #9)
> Thank you. Renaming to .xhtml fixed that issue.
>
> However, RFC 3236 clearly states
>
> There are three known file extensions that are currently in use
> for XHTML 1.0; ".xht", ".xhtml", and ".html".
>
> So I don’t consider this bug as invalid.
If the file name is .html, it didn't render as you expected to see as a xhtml. I got the same results on both firefox and chrome.
As you said, .html is also currently in use; however, to have a file handled as xhtml correctly, the type should be assigned correctly. I am also thinking of closing this as invalid.
|
|
Reporter | |
Comment 11•8 years ago
|
||
RFC 3236 advises against using the extension ".xml" for XHTML files and documents that ".html" is in common use. Maybe there was a confusion when implementing the mimetype detection.
|
|
||
Comment 12•8 years ago
|
||
Hi Anne, I still don't see where the problem is but I may misinterpret the spec. Would you mind chiming in?
Flags: needinfo?(annevk)
|
||
Comment 13•8 years ago
|
||
When we need to map a file extension to a MIME type we have two choices for "html": text/html and application/xhtml+xml. The latter would render vast swatches of content useless so we can't ever switch to that.
Also, an RFC stating a commonly used file extension has no baring on what we decide to map that to. It's just a convention. We might standardize that at some point in https://github.com/w3c/FileAPI/issues/51, but again we'd never map "html" to something it hasn't historically mapped to.
Status: UNCONFIRMED → RESOLVED
Closed: 8 years ago → 8 years ago
Flags: needinfo?(annevk)
Resolution: --- → INVALID
You need to log in
before you can comment on or make changes to this bug.
Description
•