Open Bug 311742 Opened 18 years ago Updated 4 months ago
Inline images from scripts that use a Location: redirect should save as the redirected filename, not something like rotate
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051007 Firefox/1.6a1 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051007 Firefox/1.6a1 If you right click on an inline image served by a script that returns a Location: header with the URL for another image, the Save As dialog gives you the filename for the script rather than the filename for the image that is being displayed. This situation commonly occurs with websites that have "random image" PHP scripts, which becomes rather annoying when you try to save more than one random image from the same script. This is essentially a variant of bug 146781, which was WONTFIXed because we don't want to request headers from the server before bringing up the Save As dialog. However, in this case, the browser has already retrieved the redirected image, so we've already got the redirected filename, we just needs to hang onto it somehow. Bug 89419, bug 229843, and bug 167047 seem to need much the same kind of fix. Reproducible: Always Steps to Reproduce: 1. Go to http://interbutt.com/misc/phpimage/test.html 2. Right click on the image and choose Save As Actual Results: The Save As dialog appears with the filename "random.php.png". Expected Results: The Save As dialog should show the actual filename of the image being displayed, for example "getfirefox_large.png". In an even odder wrinkle, if you right click on the image and select View Image, the real address of the image shows up in the address bar (it's for a different random image than the one you just saw though so it's not a workaround), but if you then right click, Save As, it suggests "random.php" as the filename (not even "random.php.jpg")! Using File, Save Page As works properly though.
This is quite annoying for me as well, and seems to be related with a Firefox/Gecko Cache issue. Or maybe it's just some silly way of handling image file names issue.
This also happens for the branch builds: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051120 Firefox/1.5 ID:2005112003 Try the following URL: http://www.customize.org/download/1915 and you'll be (visibly) redirected to: http://files.customize.org/old/wallpaper/files/4k1-0.jpg But, although the file name is displayed correctly both in the location bar and the "Element properties" dialog, an attempt to right click, then Save image as... will attempt to save as "1915.html". Also, if you right click and select "Copy image location", you'll end up with the redirecting URL in your clipboard.
Note a core issue, really. The UI is what gets the URI; it has access to the "actual" image URI if it wishes.
Assignee: file-handling → nobody
Product: Core → Firefox
QA Contact: ian → file.handling
Okay, well, as you can see, the bug I posted was a duplicate of this one. My bug was posted from Firefox 184.108.40.206, so there's still a problem, and it should be fixed.
This should be taken care of, especially now that Bug 299372 has been taken care of. Location and Content-Disposition headers, when saving links, are respected but inline images are not. Another test, illustrating the difference: http://beta.bluefang-logic.com/redir_dl/test.html
I wonder if it would have been better if Bug #299372 patched internalSave instead of patching nsContextMenu::saveLink. By patching saveLink, we ONLY catch the case where the user does a "Save Link As..." from the context menu. We don't catch cases where users do an image save, where users save from the file menu, or when any extensions that save files call saveURL or saveImageURL. If internalSave had been patched instead, then it would catch all of these cases ("Save Link" calls saveURL which calls internalSave, "Save Image" calls saveImageURL, which also calls internalSave, "Save Page As" calls saveDocument, which then calls internalSave). How feasible would it be to adapt the patch for Bug #299372 into something more general to apply to internalSave, and are there any potential undesirable side effects that we should take into consideration?
Ah, I see now. According to Bug #160454, the header sniffing was purposefully removed from internalSave, which is what broke this for all the different forms of saving. Well, so much for what I said in comment #8. So what are our options for approaching this? 1) Patch up nsContextMenu::saveImage in the same manner nsContextMenu::saveLink was patched. Relatively simple, but that won't allow extensions or other components to take advantage of this. 2) Somehow remember the header info. This'll handle the case of images if they have already been loaded. 3) Make another saving function that does sniff (internalSniffAndSave? sounds like scratch-n-sniff) and have saveLink and saveImage call that instead of the non-sniffing internalSave. 4) ...?
This problem also occurs on SeaMonkey, and it also manifests itself with URL shorteners, like those used in Twitter posts.
This 10 year old bug is still not fixed!! This bug also occurs on Firefox for Android. It does only occur with the right-click on a picture. It does work if you press Ctrl+S or File -> Save page as when the image is loaded directly (not included in a HTML).
Based on comment 12 & 13.
OS: Windows XP → All
Product: Firefox → Core
Hardware: x86 → All
You need to log in before you can comment on or make changes to this bug.