Inconsistency between default suggested filename in Save Image dialog and drag-and-drop image name with a content-disposition containing a space.

RESOLVED DUPLICATE of bug 291837

Status

()

Firefox
File Handling
RESOLVED DUPLICATE of bug 291837
10 years ago
9 years ago

People

(Reporter: Xavier Robin, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

10 years ago
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.
(Reporter)

Updated

10 years ago
Depends on: 440930
(Reporter)

Comment 1

10 years ago
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).
(Reporter)

Comment 2

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

Comment 3

9 years ago
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.
(Reporter)

Comment 4

9 years ago
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.
Depends on: 291837

Comment 5

9 years ago
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
Status: UNCONFIRMED → RESOLVED
Last Resolved: 9 years ago
No longer depends on: 291837, 440930
Resolution: --- → DUPLICATE
Duplicate of bug: 291837
You need to log in before you can comment on or make changes to this bug.