311742 - Inline images from scripts that use a Location: redirect should save as the redirected filename, not something like rotate.php.jpg

Status: NEW

(Firefox :: File Handling, defect)

Description

[Justin Kerk]

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.

Comment 1

[Ivo Goncalves]

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.

Comment 2

[Tommaso R. Donnarumma]

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.

Comment 3

[Boris Zbarsky [:bzbarsky]]

Note a core issue, really.  The UI is what gets the URI; it has access to the "actual" image URI if it wishes.

Comment 5

[Ian Weller]

Okay, well, as you can see, the bug I posted was a duplicate of this one. My bug was posted from Firefox 2.0.0.2, so there's still a problem, and it should be fixed.

Comment 7

[Matthew Turnbull [Bluefang]]

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

Comment 8

[Kai Liu]

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?

Comment 9

[Kai Liu]

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) ...?

Comment 12

[TT]

This problem also occurs on SeaMonkey, and it also manifests itself with URL shorteners, like those used in Twitter posts.

Comment 13

[Daniel Marschall]

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).

Comment 14

[YF (Yang)]

Based on comment 12 & 13.

Comment 16

[Justin Kerk]

The behaviour of the testcase has changed at some point - following the steps from the initial report, the image saves with the correct filename, but if you then reload the page to get a different image (may take more than one attempt), right click the image, and save, you get rotate.php.jpg again.

Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:67.0) Gecko/20100101 Firefox/67.0 ID:20190217214556

Comment 17

[Daniel Marschall]

I can confirm that the bug is still available in the latest version of Firefox for Windows.

I can also reproduce it on Firefox for Android - Interesting fact: For me, the bug occured at the 2nd reload. With the first reload, the random picture has not changed, and the filename was correct. With the second reload, the random picture was a different one, and then, the filename was wrong. Has the bug something to do with the cache contents?

PS: For the sake of completeness, I also tested with Chrome, and everything is okay there.

Comment 18

[Intelecis Inc]

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).

To insert image in an HTML page, use the <img> tags. It is an empty tag, containing only nature since the latter tag is not required. Just alimony in mind that you should use the <img> tag inside <body>…</body> tag. The src symbol is used to add the image source. I think you must visit the https://www.intelecis.com for getting advance information.

Comment 19

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S3. However, the bug has 4 duplicates and 13 votes.
:Gijs, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 20

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.