18226 - [4.xP]text file fails to display

Status: VERIFIED FIXED

(Core :: DOM: HTML Parser, defect, P3)

Description

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

DESCRIPTION:  The text file to be attached does not display anything.

STEPS TO REPRODUCE:
 * load attached test case

ACTUAL RESULTS:
 * nothing shows up except for some leftover bits of chrome appearing in the
content frame

EXPECTED RESULTS:
 * a plain text document showing an HTML document template

DOES NOT WORK CORRECTLY ON:
 * Linux, apprunner, 1999-11-04-08-M11

WORKS CORRECTLY ON:
 * Linux NN 4.61

ADDITIONAL INFORMATION:
I suspect the cause is the presence of DOCTYPE caused by an attempt at imitating
one of MSIE's worst "features".  Trust the MIME type.  It's the right thing to
do and it's what you've always done.  When some browsers disobey the standards,
then web developers think what they're doing is OK, and then the browsers that
do comply with the standards are seen as wrong.  It's a slippery slope.

Comment 1

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Attachment: testcase described in bug

Comment 2

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

The biggest problem with autodetection is forward compatibility.  Any new
standards are often designed to be backwards compatibile with old ones.  For
example, XHTML is designed so it can be sent as text/html and understood by
older browsers.  However, MacIE 4.5 thinks it's smarter than the content
provider, so when it sees an XML declaration, it ignores the MIME type of
text/html and offers the user the option of downloading the file.  It's unable
to display an XHTML file with an XML declaration sent as text/html because it's
too smart to just treat the file as HTML.

A problem similar to that one could easily happen to Mozilla with the current
auto-detection.  (Although this bug is pretty bad already, since it prevents
sending HTML code examples as text.  Imagine a program (kinda like lxr, but
simpler) that allowed browsing the source-code to a website.)

Depending on how the autodetection is written, you could also see problems where
Mozilla tries to interpret a file that it shouldn't try to interpret because it
thinks it knows what the file is.  That is, if some new standard is known not to
be backwards-compatible, then it will get a new MIME type so browsers that
understand the old standard don't try to interpret the new one.  If Mozilla were
to try to interpret this new standard as something else (say STTS3 as CSS), it
could crash, or do something else bad.  You might want to implement this
standard in version 6, but then you'll realize that it isn't usable on the web
until the installed base of version 5 drops to near 0, and there won't be
anything you can do about it.

Comment 3

[rickg]

This is fixed in my tree, awaiting m12.

The essential reason to keep this code (modified) is that mime-types are
occasionally absent or wrong. In those cases, this code kicks in and does the
right thing.

Comment 4

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

If it's absent, OK.  But how do you define wrong?

Comment 5

[rickg]

Fixed by making CNavDTD autodetect less aggressive when negotiating ownership.

To answer dbaron: wrong happens occasionally. I've been given .css files and
told they're HTML, and so on. Also, we can differential between text/xml and
specific xml applications (like xif and xul).

Comment 6

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

FYI, your current behavior does not comply with HTTP 1.1. Section 7.2.1 of HTTP
1.1 says:

# If
# and only if the media type is not given by a Content-Type field, the
# recipient MAY attempt to guess the media type via inspection of its
# content and/or the name extension(s) of the URI used to identify the
# resource. If the media type remains unknown, the recipient SHOULD
# treat it as type "application/octet-stream".

NN 4.x was usually quite good at complying with this statement.

See http://www.ics.uci.edu/pub/ietf/http/rfc2616.txt

Also, shouldn't the differentiation of XML applications be done using namespaces?

Comment 7

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

The autodetection issues were filed as bug 18817.

Comment 8

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Verified fixed, Linux mozilla 1999-11-22-08-M12.

Comment 9

[Pulsebot]

Pushed by ffxbld-merge:
https://hg.mozilla.org/releases/mozilla-beta/rev/b7a1a6fb2ce9
[fenix] For https://github.com/mozilla-mobile/fenix/issues/18226: Fixed display of tabs for when text size is set to largest (https://github.com/mozilla-mobile/fenix/pull/19046)