type description in "opening foo" dialog doesn't match mime type

NEW
Unassigned

Status

()

Firefox
File Handling
P2
normal
14 years ago
2 years ago

People

(Reporter: Hixie (not reading bugmail), Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

14 years ago
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.
(Reporter)

Comment 2

14 years ago
> 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))
(Reporter)

Comment 5

14 years ago
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".
Summary: Mozilla lies when it does extension sniffing (and looks stupid doing so) → type description in "opening foo" dialog doesn't match mime type
> 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.
(Reporter)

Comment 9

14 years ago
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.
(Reporter)

Comment 11

14 years ago
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. :-)
Assignee: file-handling → cbiesinger

Comment 12

13 years ago
(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?

Comment 13

11 years ago
(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.
QA Contact: ian → file-handling
Assignee: cbiesinger → nobody

Updated

2 years ago
Component: File Handling → File Handling
Product: Core → Firefox
Version: Trunk → unspecified
You need to log in before you can comment on or make changes to this bug.