search

gyng / save-in

WebExtension for saving media, links, or selections into user-defined directories
MIT License
208 stars 26 forks source link

Content type not driving file extension (different than Firefox "Save Image As") #134

Closed irvinm closed 4 years ago

irvinm commented 4 years ago

It doesn't appear that the content type is driving the file extension in some cases.

Example:

https://images.bloomingdalesassets.com/is/image/BLM/products/2/optimized/10631592_fpx.tif?op_sharpen=1&wid=1200&fit=fit,1&$filtersm$&fmt=webp

In this case, the file name is 10631592_fpx.tif but the content type being reported is "image/webp". "Save As..." saves the file as "10631592_fpx.tif" but that file will look like a corrupted TIF file by most viewers. If the file is simply renamed to 10631592_fpx.webp the file will open properly with an appropriate viewer. [There is no easy way to tell if *.TIF is actually a TIF, WEBP or corrupted without trying different extensions which is obviously tedious]

Also, if you use the default Firefox "Save Image As..." right-click option, it will be properly saved as 10631592_fpx.tif.webp which will be opened properly albeit a strange looking file name.

I originally thought it was more of a content type \ Firefox issue, but didn't realize the native Firefox method worked properly. (I thought an addon might be able to correct the issue: https://github.com/jscher2000/Content-Type-Fixer-extension/issues/2)

Any thoughts or suggestions?

gyng commented 4 years ago

Sorry for the late response. save-in cannot sniff the mimetype right now. There's a feature request for this in #43, but don't expect to see any progress on it soon.

If FF implements onDeterminingFilename #143, it should fix this issue too.

irvinm commented 4 years ago

Thanks for the update @gyng. We can track progress around this topic via the issues you referenced. It looks like it might be a while for either to make any progress. Thankfully this doesn't happen too often in the wild.