User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1 When saving an image with a content-disposition containing a space, the suggested file name in the Save Image dialog is different from the name automatically given to the file when if is saved using drag-and-drop. This is probably related to bug 221028 (but not exactly a dupe) and to bug 440930 (not really a dupe, more a dependency). Reproducible: Always Steps to Reproduce: 1. Go to a page containing an image with a content-disposition: containing a space (eg. http://bp2.blogger.com/_1bKnHq3a-W8/SI-QLCbh5bI/AAAAAAAABFk/8KWq_R_lC8Y/s1600-h/Picture+6.png) 2. Right clic on the image and choose "Save Image As...". 3. Note the proposed filename: Picture.png 4. Back to the image, drag-and-drop it to your desktop or a folder to save it 5. Note the filename: Picture+6.png Actual Results: different filenames Expected Results: same file name IMO, it would be best if the Save Image dialog proposed filename was changed to be consistent with the drag-and-drop one (ie complete filename is used). But as bug 221028 is WONTFIX, it would be consistent to make drag-and-drop behave as Save Image dialog (ie filename truncated at first space). This could be done by just resolving bug 440930. At least, a consistent behaviour should be adopted.

Testcase URL above was fixed by google (issue 693 on gdata-issues) so I'll try to find another testcase. This should work for any image with content-disposition: attachment;filename=blah blah.png (not quoted).

I set a testcase up in http://smilissimo.free.fr/tests/449588/test.html It should work as for initial comment.

description of this bug: "save file as" uses (if given) the filename defined in content-disposition (right behavior); drag&drop uses for the filename a part of the URL even though there is a content-disposition (wrong behavior). I think this is a dupe of of bug 291837 / bug 440930, because they are about the same thing which i described here.

I don't think it's exactly a dupe because solving bug 291837 is only one of the possibilities to fix this bug. The other being *not* to use content-disposition at all in File > Save as. I was not saying that one or the other was wrong or right, just that they must be consistent whatever the name used. But right, that's probably the best way to do and that would make sense to mark it as duplicate. At least there is a dependency here.

Not using the filename specified in the content-disposition header is definitely wrong. See HTTP specs (RFC 2616): "The Content-Disposition response-header field has been proposed as a means for the origin server to suggest a default filename if the user requests that the content is saved to a file." http://tools.ietf.org/html/rfc2616#section-19.5.1