491869 - Wrong file type displayed in open/download dialog for unknown content type

Status: RESOLVED WORKSFORME

(Firefox :: File Handling, defect)

Description

[hjp]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.7) Gecko/2009032803 Iceweasel/3.0.6 (Debian-3.0.6-1)
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.7) Gecko/2009032803 Iceweasel/3.0.6 (Debian-3.0.6-1)

[this problem isn't new, and I'm almost sure this is a duplicate, but I can't find a matching bug report]

The open/download dialog tries to display a "user friendly" description of the file type instead of the content-type. If the content-type isn't known it tries to guess from the URL. This leads to very unhelpful and confusing messages like 
"which is a: CGI file", or, as shown in the attached screen shot, "which is a: PDF file", when the content-type is actually "application/octet-stream". Since the actual content-type isn't shown, the user has no idea why the browser chooses an inappropriate helper application (gvim instead of a PDF viewer in the example), and even worse, may change the helper application for the (invisible) content-type and then be surprised that the other file type stops working.

Reproducible: Always



Expected Results:  
The dialog should show the content-type, not some guess. It may show a user-friendly description *in* *addition* to the content-type (e.g., something like "application/vnd.openxmlformats-officedocument (MS Word 2007 File)", but the content-type is important and must not be hidden.

Comment 1

[hjp]

Attachment: open dialog plus http header

The screen shot shows the open dialog which informs the user that he is about to open a "PDF file", and suggests to use "/usr/bin/gvim" for the purpose. The ethereal output to the right reveils that the response was actually of type "application/octet-stream".

Comment 2

[Sylvain Pasche]

hmm, I wonder how a "normal" user would react when seeing something like "application/vnd.openxmlformats-officedocument" in the UI. My guess is that they would be pretty confused.

Comment 3

[Alex Haan]

I surely got confused when I followed a link to a CGI script that has content type "video/x-ms-asf" but was showing as a "CGI file".

I actually thought the content provider had done things wrong. I even already started writing a message, when I decided to check the content type sent in the header.

I'm not sure whether the content provider can give the file a description of the content though. But this is really confusing me. Especially in the case of (CGI) scripts which usually are not downloaded but executed, thus the extension of such a script is not of any relation to the content.

Comment 4

[hjp]

It's ok to show a "human readable" description. But that *must* be derived from the content type, not the URL. It must not claim that the document is a PDF file when the content-type is not application/pdf, and it must never claim that the document is a "CGI file" or "PHP file" or something like that. If nothing is known about the content type it's better to show the plain content type (maybe with "unknown file format" in parentheses) than completely wrong and misleading information.

Comment 5

[Tim Bannister]

Attachment: Screen shot showing new correct behaviour

I have just tested this whilst filing bug 613727

I could not reproduce the behaviour described. When I visit http://sharing.c8h10n4o2.org.uk/Debian%20FAQ.pdf using a more recent Firefox, I get a different dialog window, correctly reflecting the metadata set by the server.


Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB;
rv:1.9.2.12) Gecko/20101026 Firefox/3.6.12

Comment 6

[Tim Bannister]

HTTP headers for my test case:

HTTP/1.1 200 OK
Date: Sat, 20 Nov 2010 14:11:12 GMT
Server: Apache/2.2
Last-Modified: Sat, 20 Nov 2010 13:53:11 GMT
ETag: "82c9-811fc-4957c57f4ffc0"
Accept-Ranges: bytes
Content-Length: 528892
Content-Type: application/octet-stream

Comment 7

[hjp]

Attachment: Screenshot with still broken behaviour on Linux

I still see the broken behaviour on 

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.12) Gecko/20101026 Firefox/3.6.12

(See screenshot)

Maybe it's platform specific.

Comment 8

[hjp]

Firefox on Windows also seems to guess the file type from the extension.

Tested with 

Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.2.12) Gecko/20101026 Firefox/3.6.12 ( .NET CLR 3.5.30729)

So for now it looks like it works correctly only on the Mac

Comment 9

[Michal 'hramrach' Suchanek]

this is probably duplicate of bug 300169

Comment 10

[Milan Bouchet-Valat]

Yes, I confirm this is a duplicate of bug 300169. An issue which is raised here and not in the other report, though, is that (at least on Linux), the application suggested to open the file doesn't match the content type detected from the extension. It appears to always be the default text editor (gedit in my case).

Comment 11

[Manuela Muntean [Away]]

WFM with latest Nightly, build ID: 20130825030201.

Please reopen this bug if you can still reproduce the issue.