277495 - Show error in JS console when file sent as text/plain is sniffed as a different MIME type

Status: NEW

(Firefox :: File Handling, enhancement)

Description

[Steve Chapel]

Currently, Mozilla reports an error when CSS files are served as a MIME type
other than text/css. There's also a request (bug 155830) for an error when the
actual type of an image doesn't match the MIME type it's sent with.

This bug is a request for a similar message sent to the JavaScript console when
a file is sent as text/plain, and it's sniffed as a binary file and the MIME
type is inferred from its contents. This message will help alert web developers
to errors in their server configuration or server scripts. Although this MIME
type error does not currently cause a problem in Mozilla, it does cause a
problem in older Mozilla browsers, may cause a problem in future Mozilla
browsers, and can cause a problem in IE and Opera if the user has turned off
MIME type sniffing in those browsers.

Comment 1

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

ok, I want to WONTFIX this bug as written. Instead, for these cases, the helper
app dialog should indicate that the content type was sniffed. I was pretty sure
that we have a bug on that already, but I'm unable to find it...

note: we always show the helper app dialog when we sniff text/plain content

Comment 2

[Steve Chapel]

When I click on the sample URL above using Mozilla trunk build 2005010711 on
Windows XP SP 2, I don't get any helper app dialog. This is despite the fact
that it's a Windows Media Video file sent as text/plain.

The closest I cound find to a bug that requests information about MIME type
sniffing info on the helper app dialog is bug 229688. It would be great if that
dialog could appear and indicate the MIME type sent by the server and the
sniffed MIME type. I agree we wouldn't need a JS console error if that were the
case.

Comment 3

[Boris Zbarsky [:bzbarsky]]

Problem one is that the sniffer case doesn't _force_ the dialog.  If the user
has indicated that a type is to be handled without asking, and if we sniff
things to be that type, we will never show the dialog.

The right answer is to make this case force the dialog, and to have the dialog
text say the right thing.  I also thought we had a bug on the latter issue, but
I can't find it.  So perhaps this should become that bug?  Or perhaps that bug
needs to be filed (and this bug wontfixed, since I agree with biesi that doing
what the summary suggests is not so useful)?

Comment 4

[Boris Zbarsky [:bzbarsky]]

Oh, ccing Ben since changing the back end to force the dialog here would affect
Firefox UI.  I think the thing to do is to change that call into the dialog from
having a boolean to having a "reason" the dialog is posed
("content-disposition", "sniffed type", "not set to handle automatically" being
the three reasons I can think of, possibly as a bitfield) and then having the UI
handle the reason as it sees fit...