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.
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
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → INVALID
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...
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
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.
Sounds good. Rubber-stamping as verified since y'all agree. ;) Thanks for the intriguing info; enjoyed reading it.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.