The header "Content-Disposition" with parameter "inline; filename=somefile.ext" is ignored when saving content. The save name is supposed to be the one suggested by the header, instead it's the URL. This is a nuisance on a fair amount of sites; for instance forum software like Invision Board serve attached files this way. Bugzilla is another example. As mentioned in the attached testcase, saving from the Page Info Media tab also presents the wrong filename (bug 491208), while Save Page As and Save Link As show the correct filename. * I've tested the current release, beta and aurora (15.0.1, 16.0b2, 17.02) and they all work correctly on Save Image As. * Nightly dated August 31st also works correctly on Save Image As. * Nightly dated September 1st has the problem, same as the latest one.

Reporter: Could you please post the 2 build revisions from the last working and first bad build ? The revision in visible in about:buildconfig (e.g. Built from http://hg.mozilla.org/mozilla-central/rev/a86b00fa6bc6 )

I tested what was labeled -mozilla-central/. I don't know if there were other builds in that 24-hour period. August 31st Built from http://hg.mozilla.org/mozilla-central/rev/fcc533f691e9 September 1st Built from http://hg.mozilla.org/mozilla-central/rev/a21fd4d085ad I don't know what went wrong with the attachment, by the way. I first uploaded with content type set to auto and it ended up as text/plain. I then reuploaded with content type set to "select from list: HTML source (text/html)" but as you can see it ended up as text/plain anyway.

via tinderbox hourly build I got this regression range http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=054016215c5e&tochange=bdc68f5ddb38 I hope I didn't do something wrong as I had to do that manually (we need either a better regression searching tool or better documentation of it)

bz: should we dupe this one to bug 789546 ? It looks like this is basically the same issue ?

(In reply to Matthias Versen (Matti) from comment #5) > bz: should we dupe this one to bug 789546 ? > It looks like this is basically the same issue ? I don't get it. That one's about data: URI images on Android lacking a file extension when saved. Server headers don't even come into play there.

> Server headers don't even come into play there. Yes, but the point is that this bug appeared at the same time as that one, and was caused by the same checkin. So there's a good chance they're related. Marking dependent for now.

Hmm, the patch in bug 789546 solves #1, #3, and #4 in the testcase. #2 still shows attachment.cgi, and I am confused.

Did #2 use to show attachment.cgi before as well? Chances are the page info code is just dumb and doesn't use the right "save as" codepaths... If #2 used to work, then the next most likely thing is that now the image cache is per-document and page info is not the same document as the original image?

I don't have access to a non-nightly build right now (various problems with official releases failing to run on my machine) so I can't confirm, but the Page Info code definitely does flow through an alternate path than the rest (specifically, it doesn't appear to access the image cache at all, unlike the rest). My suspicion is that it displays the same behaviour in older releases.

#2 is no regression and is probably related to bug 415225 I can confirm that Firefox15 wants to save it as attachment.cgi

Sounds like this is fixed, then.