310024 - When saving certain pages, no format options are given

Status: RESOLVED INCOMPLETE

(Camino Graveyard :: Downloading, defect)

Description

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

When saving certain pages, like Bugzilla query results, the user is not offered
a choice of file formats but instead must save the page as regular HTML.

Further, the suggested filename has an extraneous trailing quote, e.g.
bugs-2005-09-25.html" instead of bugs-2005-09-25.html (bugs-2005-09-25.html is
what the content-disposition header returns as the filename).

(The extraneous quote thing looks familiar, but I can't find the bug where it
came up before....)

Camino 2005092404 (v1.0a1+)

Comment 1

[Mike Pinkerton (not reading bugmail)]

might be easy for 1.0

Comment 2

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

I'm not seeing the extraneous quote in the suggested filename anymore, so whatever that was, it's gotten fixed along the way.

Comment 3

[Samuel Sidler (old account; do not CC)]

(In reply to comment #1)
> might be easy for 1.0
> 

Might be? Psh... :-P

Comment 4

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

Mass un-setting milestone per 1.6 roadmap.

Filter on RemoveRedonkulousBuglist to remove bugspam.

Developers: if you have a patch in hand for one of these bugs, you may pull the bug back to 1.6 *at that point*.

Comment 5

[Chris Lawson (gone)]

In case this helps someone later:

url -I "https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=option&product=Camino&resolution=---"
HTTP/1.1 200 OK
Date: Tue, 28 Oct 2008 15:48:23 GMT
Server: Apache/2.2.3 (Red Hat)
Content-disposition: inline; filename="bugs-2008-10-28.html"
Set-Cookie: LASTORDER=bugs.bug_status%2C%20bugs.priority%2C%20map_assigned_to.login_name%2C%20bugs.bug_id; path=/; expires=Fri, 01-Jan-2038 00:00:00 GMT
Set-Cookie: BUGLIST=300408%3A303548%3A310024%3A317287%3A326589%3A340569%3A341977%3A356705%3A384691%3A409679%3A219056; path=/; expires=Fri, 01-Jan-2038 00:00:00 GMT
X-Backend-Server: mrapp52
Content-Type: text/html; charset=UTF-8

I don't see anything particularly interesting in there myself.

Comment 6

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

Grr, this is even worse now; we don't even get the content-disposition filename suggested, but rather "buglist.cgi".

I'll have to dump my logging back into SaveHeaderSniffer sometime and see what's going wrong here.

Comment 7

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

Attachment: Filename logging patch

Ugh, this is a mess.  There are now multipls problems:

1) (Explaining the original bug as filed) The nsIURI we have fails the |isHTML| check, because mContentType is "multipart/x-mixed-replace" [1]

2) (Explaining the current sucky filename) mContentDisposition on the nsIURI is empty, which means we skip preferred filename option 1, getting the name from the HTTP headers [2]

As a result of those two foibles, we fall back to getting the filename from the "file" portion of the URL, which is "buglist.cgi".

I suppose we could work around the |isHTML| failure by adding "multipart/x-mixed-replace" to the isHTML content-types, but that seems wrong (and dangerous, given that the replaced content is not guaranteed to be HTML; that content-type is used, e.g., for old-fashioned still-image webcams).

Firefox 3.6 gets this right, and their logic is/was very similar to ours (right down to the comments!)--but I can't find that anymore, so I don't know if this is related to our sniffing, or to something like bug 299372, or what…

I've attached my logging patch so that anyone who wants to investigate these types of bugs can just apply the patch, without having to figure out all the crappy Gecko string types themselves ;-)

[1] http://mxr.mozilla.org/camino/source/camino/src/download/SaveHeaderSniffer.mm#190
[2] http://mxr.mozilla.org/camino/source/camino/src/download/SaveHeaderSniffer.mm#211

Comment 8

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

Oh, it's getDefaultFilename in http://mxr.mozilla.org/mozilla1.9.2/source/toolkit/content/contentAreaUtils.js#864

Note, though, that at the start of the process (way before getting to that function), in saveDocument(), they try again to get the content-disposition: http://mxr.mozilla.org/mozilla1.9.2/source/toolkit/content/contentAreaUtils.js#169

I'm not sure where that might be in our code; maybe that's the problem for this page-type?