28264 - Cannot open image file with an unusual extension

Status: VERIFIED INVALID

(Core :: Graphics: ImageLib, defect, P3)

Description

[Marc Attinasi]

When you try to open a GIF image that has an extension like GGF instead of GIF 
you get the SaveAs / PickApp dialog. Nav4 has no problem with this same image. 
This occurs if you use the OpenFile menu item or type the name into the address 
bar.

Also, if you load a page that has an image in it, and the image has an unusual 
extension, then the image shows up in the page, but selecting 'view image' from 
the menu causes the SaveAs / PickApp dialog instead of displaying it.

Comment 1

[pnunn]

The browser has to have some sort of clue that an image
is a file of image data. 

When an html tag of <img src=blah.too> happens, 
we can bet the data in 'blah.too' should go to the
image library. When we have a mimetype mapping with
a known file extension like ".gif", ".jpg", ".png"
we route the data stream to the image library.

If the image library gets a data file and it has a bogus
extension, but it is one of a few of the standard
file types, we can recognize its true mime type and
continue decoding it. For example, you have a gif file, but
you got hit on the head and renamed it blah.jpg instead of
blah.gif, the data would be sent to the image library 
because ".jpg" is a standard extension. The image library 
is smart enough to recognize it as a standard type and decode
it anyway. 

There will be a way to add image data mime types on the fly, but
I don't think necko supports this yet.
-pn

Comment 2

[Marc Attinasi]

Based on compatibility alone this seems like a valid bug.

Nav4 deals with it for drag-and-drop, file open and view-image. I guess Nav4 
checks every unknown extension to see if it can decode it as an image... pretty 
cool.

IE5 deals with it for drag-and-drop but not file-open and not view-image. Also, 
IE freaks out if you have a GIF with a JPG or JPEG extension, but not if you 
have a GIF with an extension FOO... go figure.

I'll let you decide if it is valid or not, but please reconsider it given the 
combatibility angle...

Comment 3

[pnunn]

In the long run this will be cooler.
In Nav 4.x, you have a fixed list of supported image files.
And it is a short list.

In the new world, you could develope an absolutely brilliant
compression method and file format. Its proprietary, but you
can easily make it a mozilla image decoder component by slapping
a thin wrapper on it and putting it in the bin/components directory.

Your new files have a "*.att" extension (or whatever), so you
add the file extension to map to the attinasi decoder component
mime type which could be ".att" to "image/x-att". 
The browser when ever it sees an ".att" extension, know it is
an image data stream, and sends it to the image library. The image
library doesn't see it in the short list of standard image formats
so it looks to see if it has a decoder registered for "image/x-att"
in the bin/components directory. It finds your decoder and your image
is displayed from your proprietary format _inline_. Not a plugin.

If your friend wants to see the images, you send them the decoder and
tell them to drop it in the bin/components directory. And they click
on a dialog to add the extension to mime type mapping. And they can
view the proprietary images inline.

I think this is pretty cool.

If we scanned every unknown mime type file, just on the off chance
it might be an image file and might belong a fixed list of known
image formats, the browser would be dog slow. And that is what
we would have to do. Telepathy doesn't work. We have to know its an
image file somehow.

Perhaps we need to expand what necko understands for file extension
mapping, but that is a matter of updating a list in necko. Do you
want to add GGF to the gif mapping?

-pn

Drag and drop is a different animal and a different discussion.
-P

Comment 4

[Marc Attinasi]

No, I don't want to add GGF to the image mapping, but I do like the idea of 
adding ATT ;)

I get your point and I see why Mozilla and Nav do it differently. I'm cool with 
it now that I've been enlightened.

Comment 5

[Eli Goldberg]

Sounds good. Rubber-stamping as verified since y'all agree. ;)

Thanks for the intriguing info; enjoyed reading it.

Comment 6

[BMO Automation]

Attachment: [mozilla-mobile/fenix] For #28264 - Refactor synced tabs handling out of `NavigationInteractor` (#28443)