266410 - Text file treated as binary

Status: RESOLVED INCOMPLETE

(Firefox :: File Handling, defect)

Description

[Patricio Stegmann]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20041001 Firefox/0.10.1
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20041001 Firefox/0.10.1

The file contains some non printable "funny" chars but is being treated as
binary, even if mime-type is text and extension is .txt
Removing the strange chars make it work again.
It is impossible to force opening of the file with firefox (chosing the application)
If I remove the funny characters it opens as it should !

Reproducible: Always
Steps to Reproduce:
1.Go to the posted URL
2.See the "Save file" dialog
3.Check the mime type and the file content ==> it is text !

Actual Results:  
The save dialog appeared on http://kpoman.free.fr/buggyfile.txt

Expected Results:  
I should have get the content of the txt file ... It works if I remove the funny
chars: http://kpoman.free.fr/goodfilefile.txt

Comment 1

[OstGote!]

Because a lot of webservers send the wrong MIME type text/plain for other files
Mozilla uses a detection mechanism for text/plain, which fails here. See Bug
220807. I get a save dialog with MIME type text/rfc822 (eml).

Comment 2

[Jean-Marc Desperrier]

I believe this is *not* the behaviour that was supposed to be implemented
initially by the fix to bug 220807.

The initial request was to give the user the option to still "Display as plain
text" whenever the browser thought the file was likely to not be plain/text.
As the detection alg can not be garanteed to always correctly identify the file
type, the option to do that is really needed.

And we have the fact that if two ^H character in the whole file are enough to
make it binary, then the detector is too strict.

Comment 3

[Boris Zbarsky [:bzbarsky]]

The fact is, this file is not in fact plaintext.  We have an existing bug on
being able to force "view as text", so feel free to dup this or mark it invalid
at your discretion.

Comment 4

[Daniel Jackson]

This slightly different to just a "force view as text" option (Bug 57342, I 
assume), as we are dealing here with something that the server has declared is 
plain text in the first place.

The only practical difference is that I would prefer it if the browser 
explained why the file was being treated abnormally.  Along the lines of:

  "...has been sent as plain text but appears to be binary data"

...Perhaps also a different default (if "do this from now on" is not selected).

Comment 5

[Christian :Biesinger (don't email me, ping me on IRC)]

>  "...has been sent as plain text but appears to be binary data"

yeah, that text really should be changed. we probably have a bug on that already...

Comment 6

[Jean-Marc Desperrier]

Well, they are two issues :

1 - If a file sent as text/plain is thought by mozilla to be binary, there is no
way to display it as text/plain inside mozilla :

Implementing bug 57342 would solve this problem in an acceptable manner.
But bug 57342 desn't seem likely to be solved rapidly, and it concerns a much
larger scale problem.

The fact the fix to bug 220807 was implemented in a way where the browser will
contredict the instructions he received from the server *without* giving the
user the option to revert to the normal behaviour was a bad idea, and a much
more urgent problem to solve than bug 57342.

2 - Files including the character ^H (\b in C language syntax) will be
interpreted as binary and not as valid text/plain :

RFC2046 quite strongly discourages, but does not strictly forbid, the inclusion
of control characters and DEL inside text/plain documents. 
The list in the RFC of control characters having a de facto meanings in wide use
is *very* restricted, and some more character have a wide use.

The current patch already ignores \v "vertical tab" that is not listed in the RFC.

Modifying the binary detector to add \b "backspace" to the ignored control char
list would be a very reasonnable option in my opinion, and would solve the
problem for this file.

I'm thinking about providing a 1-line-patch for 2, and opening a separate bug for 1.

Comment 7

[Christian :Biesinger (don't email me, ping me on IRC)]

>But bug 57342 desn't seem likely to be solved rapidly, and it concerns a much
>larger scale problem.

but it must be fixed to allow fixing your issue 1. or rather, the hard part is
the backend, and that issue needs the same changes as that bug.

Comment 8

[Jesse Ruderman]

Dup of bug 247509?

Comment 9

[BugBot [:suhaib / :marco/ :calixte]]

In the process of migrating remaining bugs to the new severity system, the severity for this bug cannot be automatically determined. Please retriage this bug using the new severity system.

Comment 10

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:Gijs, could you have a look please?

For more information, please visit BugBot documentation.

Comment 11

[:Gijs (out for now; he/him)]

The testcases are gone and we have much better specs on this kind of thing now. Let's close as incomplete and file new bugs (Feel free to CC me) if we're somehow not doing what the spec says or we think the spec and our behaviour need to change.