243981 - Filename in Save As dialog has an extra quote symbol at the end of the suggested name

Status: RESOLVED INVALID

(Camino Graveyard :: General, defect)

Description

[Paul Donovan]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7) Gecko/20040517 Camino/0.8b
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7) Gecko/20040517 Camino/0.8b

On any page that shows a list of bugs at http://bugzilla.mozilla.org, selecting
Save As prompts the user to save a filename of the form 'bugs-2004-05-18.html"'.
Note the extra double quote after the .html extension.


Reproducible: Always
Steps to Reproduce:
1. Go to
http://bugzilla.mozilla.org/buglist.cgi?query_format=&short_desc_type=allwordssubstr&short_desc=save+as&product=Camino&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailassigned_to1=1&emailtype1=exact&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailtype2=exact&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=
2. Choose File->Save As...


Actual Results:  
The filename in the 'Save As:' field of the save panel is bugs-2004-05-18.html"

Expected Results:  
The filename should be bugs-2004-05-18.html

Comment 1

[Stuart Morgan]

Yep.

We are extracting this filename from the Content-disposition header, right here:
http://lxr.mozilla.org/mozilla/source/camino/src/download/SaveHeaderSniffer.mm#210
and getting |bugs-2004-05-18.html\"|

I'm not sure what's going wrong, exactly, but I imagine it might be related to
this, which is generated when that line executes:
###!!! ASSERTION: aTryLocaleCharset not yet supported !: '!aTryLocaleCharset',
file nsMIMEHeaderParamImpl.cpp, line 95
Break: at file nsMIMEHeaderParamImpl.cpp, line 95

Comment 2

[Mike Pinkerton (not reading bugmail)]

does this happen in ff?

Comment 3

[Stuart Morgan]

It works fine Firefox 0.8; I haven't tried a nightly build.

Comment 4

[Paul Donovan]

(In reply to comment #3)
> It works fine Firefox 0.8; I haven't tried a nightly build.

It works fine with a build I did a week ago (20040510 Firefox/0.8.0+). I haven't
tried a newer one.

Comment 5

[Steve Ruge]

2004082512 (v0.8.1): Still occuring.

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; rv:1.7.3) Gecko/20040913
Firefox/0.10: Does not occur.

Comment 6

[Josh Aas]

I thought I fixed this a long time ago...

Comment 7

[Josh Aas]

We get the content-disposition filename suggestions with this:

            rv = mimehdrpar->GetParameter(mContentDisposition, "filename",
                                          fallbackCharset, PR_TRUE, nsnull,
                                          defaultFileName);

You can use the following code to check the file name it returns:

NSLog(@"string: %@", [NSString stringWithCharacters:defaultFileName.get()
length:defaultFileName.Length()]);

We are getting the bad value with the extra quote at the end from necko/gecko,
so its not our fault. This must be happening in other apps.

bryner? darin?

Use a bugzilla search result list to test this bug...

Comment 8

[Josh Aas]

What I mean to say, to clarify, is that content disposition GetParameter(...) is
not parsing the HTTP(S) header correctly.

Comment 9

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

(In reply to comment #7)

> We are getting the bad value with the extra quote at the end from necko/gecko,
> so its not our fault. This must be happening in other apps.
> 
> Use a bugzilla search result list to test this bug...

I used the search result link in comment 0.  I can confirm that the released
Firefox 1.0 *does not* have the problem (I don't have a trunk build of fx to
test), so it's not happening in *all* other apps, but Camino 2004121208 (v0.8+)
and 0.8.2 indeed *do* have the spurious trailing double quote.

Comment 10

[Josh Aas]

I disagree. I don't think FF is using the content disposition header in your
test. There are about 5 different places it could be getting a save name...

Comment 11

[Christian :Biesinger (don't email me, ping me on IRC)]

so, what's the exact header mozilla sees here?

Comment 12

[Josh Aas]

HTTP response header Content-disposition line:

"inline; filename=bugs-2004-12-17.html"[CRLF]

That is from a bmo query.

Comment 13

[Josh Aas]

This is a problem with bugzilla, not with Camino. Did some detective work with
biesi...

Basically, in the case of bmo we are getting the filename from the
content-disposition HTTP header. The header is not supposed to be quoted
according to the HTTP rfc, but bugzilla quotes the whole value. Only the
filename is allowed to be quoted in the header. We don't get rid of the last
quote because the filename does not begin with a quote. So:

"inline; filename=bugs-2004-12-17.html"[CRLF]

Should be:

inline; filename="bugs-2004-12-17.html"[CRLF]

Filing bug against bmo... We behave according to RFCs 2183 and 2616 and bmo is
the only place you're likely to find this bug.