Closed Bug 40060 Opened 25 years ago Closed 25 years ago

text/plain displayed only if interpreted as HTML

Categories

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

Product:
Core
Component:
DOM: HTML Parser
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: BenB, Assigned: rickg)

References

(
URL
)

Details

(Whiteboard: [nsbeta2+])

Attachments

(2 files)

short text/plain file with HTML spoor (<B>a </B>)
(deleted), text/plain
Details
short text/plain file without HTML spoor
(deleted), text/plain
Details
Reproduce: 1. Load a .txt file into the browser Actual result: There are no line wraps Reproduce: 1. Create a file foo.txt containing "<b>bla</b>" 2. Load it in the browser Actual result: "bla" in bold Expected result: "<b>bla</b>" not bold.
The same happens with documents served as text/plain over HTTP, like, say: http://www.bath.ac.uk/%7Epy8ieh/internet/discussion/metadata.txt Nominating for nsbeta2 because this really is a dogfood problem (the document given above is a spec for Mozilla UI behaviour, and this bug makes it unusable).
Keywords: nsbeta2
When this will be fixed, please please fix it by fixing bug 39042.
Setting severity to Major. Changing summary from "Display of text/plain interpreted as HTML" to "text/plain displayed only if interpreted as HTML" Using the 2000-05-21-08-M16 nightly binary on WinNT, content served as text/plain or read from a .txt file is not displayed at all unless it is (falsely) identified as HTML. Mozilla does its best to recognize the content type from the content itself if it is not told by metadata, but that should not be happening when the content is served as text/plain or retrieved from a .txt file. The two attachments are full of the string "aaaa " repeated to fill out 1k, 80 characters per line, except that the first starts with "<B>a </B>". Only the first displays; the "<B>a </B>" is interpreted as a bold "a".
Severity: normal → major
Summary: Display of text/plain interpreted as HTML → text/plain displayed only if interpreted as HTML
This is a more detailed variant of bug #39383, so I suggest that one be closed as a duplicate of the other. Since this one has more detail and a more exact diagnosis of the problem, I suggest closing #39383 as the dup. I believe that this should (and must) be a NSBETA2 bug, and a high priority one. Releasing a beta browser that cannot correctly show text/plain documents is not exactly going to impress anyone.
*** Bug 39383 has been marked as a duplicate of this bug. ***
Some more test cases: <http://utcc.utoronto.ca/abuse/usenet/2000-05-15-src.txt> <http://www.gnu.org/copyleft/gpl.txt>. Ian, Chris, are you sure, the server reports "text/plain" as Content-Type?
URL: http://utcc.utoronto.ca/abuse/usenet/...
Yes, the servers for all of the testcases listed here specify "text/plain" as the content type. This can be verified for all but the attachments by using Delorie's HTTP Header Viewer at http://www.delorie.com/web/headers.html -- the attachments are sent server-push, which confuses that viewer. Alternatively, view the page with NN 4.x, then use View>Page Info.
*** Bug 40096 has been marked as a duplicate of this bug. ***
This is an incredibly lame problem that I introduced when I rewrote the doctype autodetection code. Fixed in my tree, awaiting chance to land.
Status: NEW → ASSIGNED
Blocks: 31989
Putting on [nsbeta2+] radar for beta2 fix.
Whiteboard: [nsbeta2+]
Severity: major → blocker
Keywords: smoketest
removing from blocker list, per rickg's email. checkin expected in the morning, that is good enough for me.
Severity: blocker → critical
Keywords: smoketest
Fixed by change to doctype handling code.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
this may or may not be releated to this bug - so i'll post a new one if it's not. i'm noticing that for CGI output, this is still broken unless i specifically put in a <html> tag, the text is not displayed and i get a blank page instead.
Jae, what you saw is bug 40741, "HTML file with no markup doesn't display", fix in hand. Putting <html></html> into cgi output is safest anyway, though.
Verified 2000-07-12-11-M17 : Linux 2000-07-12-09-M17 : WinNT & Win98 2000-07-12-13-M17 : Mac
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: