STEPS TO REPRODUCE 1. Visit http://www.hixie.ch/tests/adhoc/http/content-type/010.png ACTUAL RESULTS || Opening 010.png ||||||||||||||||||||||||||||||||||||||||||||||||||||||| | ____ | | The file "010.png" is of type image/png (ACDSee PNG Image), | |\ | | and Mozilla does not know how to handle this file type. This | PNG | | | file is located at: |Image| | | |_____| | | http://www.hixie.ch/tests/adhoc/http/content-type/010.png | | | | What should Mozilla do with this file? | | (o) Open it with the default application (ACDC_PNG) | | ( ) Open it with [___________________________________] ( Choose ) | | ( ) Save it to disk | | | | [ ] Always perform this action when handling files of this type | | | | (( OK )) ( Cancell ) | |________________________________________________________________________| EXPECTED RESULTS || Opening 010.png ||||||||||||||||||||||||||||||||||||||||||||||||||||||| | ____ | | The file "010.png" is of type application/octet-stream | ,-,|\ | | (Binary data or executable) and Mozilla does not know how to | ' | | | how to handle this file type. The file is located at: | o | | | |_____| | | http://www.hixie.ch/tests/adhoc/http/content-type/010.png | | | | What should Mozilla do with this file? | | (o) Open it with Mozilla, treating it as [ An Image |v] | | ( ) Open it with the default application (ACDC_PNG) | | ( ) Open it with [___________________________________] ( Choose ) | | ( ) Save it to disk | | | | [ ] Always perform this action when handling files of this type | | | | (( OK )) ( Cancell ) | |________________________________________________________________________| NOTES 1. We shouldn't claim the file is a PNG file since if it really was a PNG file we would have just handled it ourselves. 2. We shouldn't use the PNG icon, since it's not a PNG file. 3. We should offer to handle the file ourselves, since we think it's a PNG file and we know how to handle it ourselves. (This should be the default.) 4. The "open it with Mozilla" drop down should probably have four options: An HTML file An XML file A plain text file An image The HTML, plain text, and XML types aren't detectable; Images are. PIE IN THE SKY NOTES It would be cool, although almost certainly not something users would appreciate, to replace the checkbox with: | In future, when handling file of this type: | | (o) Ask me what to do, just like this time | | ( ) Perform the action I selected this time again | | ( ) Guess what the right action is and do it automatically | But that's another issue. OTHER TEST CASES data:application/octet-stream,fake%20plain%20text%20file data:foo/bar,test.png I can make more HTTP test cases if required.

> ACTUAL RESULTS Those are not what I see with yesterday's win32 SeaMonkey nightly, Ian. What build are you using? Shouldn't that be the first thing your bug report lists, dude? First of all, are you using SeaMonkey or Firebird? If the latter, I don't care, since they've been forking this shit right and left. If the former, what exact build? What I see is: | The file "010.png" is of type application/octet-stream (PNG Image)| etc, etc, with the preselected option being "open it with default application (pngfile)". So in summary: 1. I am not seeing the problem your note 1 mentions. 2. Note 2 is not consistent with note 3. 3. Note 3 is covered by another bug already. 4. Note 4 is covered by the same bug.

> Those are not what I see with yesterday's win32 SeaMonkey nightly, Ian. What > build are you using? I was working from memory, using a 1.5 build on someone else's machine for the general layout, and basing the actual values on what people were telling me on IRC. I don't actually have a Windows machine here. > First of all, are you using SeaMonkey or Firebird? I am told they both do the same thing here. > What I see is: > > | The file "010.png" is of type application/octet-stream (PNG Image)| > > etc, etc, with the preselected option being "open it with default application > (pngfile)". So the MIME type is correct (good!) but the rest is still wrong (wrong description, wrong icon). > 1. I am not seeing the problem your note 1 mentions. According to what you said above, you are. application/octet-stream is not a PNG image, it's a "Binary data or executable file". > 2. Note 2 is not consistent with note 3. Eh? It's not a PNG file. It's a binary file. We should use the binary file icon. > 3. Note 3 is covered by another bug already. I couldn't find that bug (I looked) -- do you know the bug #? (I thought I had commented in such a bug, but I couldn't find it, and you said to file this bug, so I did.) This bug was intended to cover points 1 and 2 primarily, apologies for the confusion.

> 2. We shouldn't use the PNG icon, since it's not a PNG file. that is totally different code (moz-icon code, probably imagelib component) > 3. We should offer to handle the file ourselves, since we think it's a PNG > file and we know how to handle it ourselves. (This should be the default.) that's mostly bug 185618... > 4. The "open it with Mozilla" drop down should probably have four options: that's bug 11521 really hmm, you really got image/png shown as mime type? I thought 1.5 had that fixed. but maybe it got fixed later... anyway... could you try a trunk build?

(a trunk build would still show application/octet-stream (PNG Image))

Did I mention the lack of Windows machine? :-) Do we have a bug over the fact that our icon is being displayed based on the filename instead of the MIME type? I can file that separately if you want. This bug is thus now purely about the fact that we say "PNG Image" when we should say "Binary File".

> Did I mention the lack of Windows machine? :-) yes :) but with the exception of the icon, this code is pretty cross-platform. >Do we have a bug over the fact that our icon is being displayed based on the >filename instead of the MIME type? no idea... if you file one, please cc neil@park and me.

oh btw. I guess the real reason we do this is that we want to lookup the helper application by extension if it fails by type. I suppose we could change that to only get the application+application description, not the mimetype description.

> I was working from memory, using a 1.5 build The type was listed incorrectly in the dialog in 1.5; that was fixed afterwards. "Please test with a current build" ;) > So the MIME type is correct (good!) but the rest is still wrong (wrong > description, wrong icon). Our policy at the moment is as follows: 1) List MIME type that came from the server 2) Offer options to handle it based on what we think it is (per your note 3) 3) Make the description consistent with what we offer to handle it with It sounds like you have issues with the third step above, right? Is there a good reason you think it would make more sense to claim that this is a 'application/octet-stream ("Binary File")' and offer a png viewer? The way we do it, the people who actually care (very few, really) get to see the original content type; the rest see the pretty description that matches the way the file will actually be treated. Please do file the separate bug on the icon, though. CC me and ben too.

That would seem better to me. If I download a application/x-printing-network-grapheme I definitely don't want to be told it's a PNG image, even if the default behaviour is to offer to render it as a PNG. After all, it isn't a PNG.

I really have no opinions on that part one way or the other, as long as we're offering the right helper by default. Ben, if you have any opinions speak now or forever hold your peace.

I found a real site that "breaks" with this: http://www.phonk.net/Images/Aigues-Mortes/991028-Aigues-Mortes.jpg;application%2Frdf%2Bxml We claim that URI is a JPEG image. It isn't. Not even close. :-)

(In reply to comment #0) > STEPS TO REPRODUCE > 1. Visit http://www.hixie.ch/tests/adhoc/http/content-type/010.png Part of the "Steps to Reproduce" in this bug should include: 0.5) If necessary, remove entry for application/octet-stream from the preferences. > ACTUAL RESULTS > NOTES > 1. We shouldn't claim the file is a PNG file since if it really was a PNG > file we would have just handled it ourselves. This is working OK -- it is shown as: application/octet-stream > 2. We shouldn't use the PNG icon, since it's not a PNG file. This is working OK -- it does use the generic binary icon. > 3. We should offer to handle the file ourselves, since we think it's a PNG > file and we know how to handle it ourselves. (This should be the default.) > 4. The "open it with Mozilla" drop down should probably have four options: These are still as described, but are already filed, per comment 3. (In reply to comment #11) > I found a real site that "breaks" with this: [...] > > We claim that URI is a JPEG image. It isn't. Not even close. :-) I'm seeing this claim in Firefox, but not in the suite. Ian, where are you seeing it? That URL's data is reported as being served as application/vnd.mozilla.xul+xml in the suite; reading with Opera, it's reported as being served as application/ rdf+xml. (I don't know how to check how it's being served to FF.) In both cases, it's being displayed basically as plain text in the browser window. I do not have an entry for application/vnd.mozilla.xul+xml in my installation's Helper Application preferences nor even in mimeTypes.rdf. The issue with FF should be filed separately, I think, if it is indeed specific to Firefox. So my question is: any reason to leave this bug open?

(In reply to comment #12) > > ACTUAL RESULTS > > NOTES > > 1. We shouldn't claim the file is a PNG file since if it really was a > > PNG file we would have just handled it ourselves. > > This is working OK -- it is shown as: application/octet-stream I should have noted back when I made this comment: the suite does show "application/octet-stream", but Firefox does not; however, both browsers claim the file is an "Image" (which is the name of a PNG file in my Windows registry). That part probably should be tweaked. See bug 293804. > > I found a real site that "breaks" with this: [...] > > > > We claim that URI is a JPEG image. It isn't. Not even close. :-) > > I'm seeing this claim in Firefox, but not in the suite. Ian, where are you > seeing it? > [in the suite] it's being displayed basically as plain text in the browser > window. Now, I see that same behavior in Firefox 2 and in Seamonkey (1.5 at the moment); definitely no image confusion going on there.

Moving to p3 because no activity for at least 1 year(s). See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information