Content-Disposition: inline; filename= doesn't work with Save As

VERIFIED FIXED in Firefox 40

Status

()

defect
VERIFIED FIXED
4 years ago
a year ago

People

(Reporter: firefoxbugs, Assigned: seth)

Tracking

(Blocks 1 bug, {regression})

39 Branch
mozilla42
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox38 unaffected, firefox38.0.5 unaffected, firefox39 affected, firefox40+ verified, firefox41+ verified, firefox42+ verified, firefox-esr31 unaffected, firefox-esr38 unaffected)

Details

(Whiteboard: [bugday-20150715])

Attachments

(2 attachments)

(Reporter)

Description

4 years ago
Posted image Beaver.jpg
User Agent: Mozilla/5.0 (Windows NT 6.1; rv:39.0) Gecko/20100101 Firefox/39.0
Build ID: 20150630154324

Steps to reproduce:

1. Click on image link
2. Right click on image select Save Image As...
3. File name shown is ...


Actual results:

File name suggested in save dialog is ...


Expected results:

Suggested file name should be Beaver.jpg
(Reporter)

Comment 1

4 years ago
Steps to reproduce:

1. Right click on image link Beaver.jpg
2. Select Open Link in New Window
3. Right click on image 
4. Select Save Image As...

Actual results:

File name suggested in save dialog is "attachment.cgi.jpg"


Expected results:

Suggested file name should be "Beaver.jpg".

Also Ctrl+S shows "Beaver.jpg".

It's regression from previous versions Firefox 38.0.5, 38.0
(Reporter)

Comment 2

4 years ago
HTTP headers show:

Connection: Keep-Alive
Content-Disposition: inline; filename="Beaver.jpg"
Content-Length: 20717
Content-Type: image/jpeg; name="Beaver.jpg"; charset=
Date: Fri, 03 Jul 2015 08:05:57 GMT
Keep-Alive: timeout=5, max=1000
Server: Apache
X-Backend-Server: web3.bugs.scl3.mozilla.com
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block

Comment 5

4 years ago
Via local build
Last Good: fcaed7860ea4
First Bad: 3f5eae4fac0f+f687743cc499

Regressed by: Bug 1139225
Blocks: 1139225
No longer blocks: 1139804

Comment 6

4 years ago
[Tracking Requested - why for this release]: Regressed by Bug 1139225 since Firefox39
This is a regression which will impact a lot of our end-users. Adding a tracking flag for FF40, FF41 and FF42.
(Assignee)

Comment 8

4 years ago
Unfortunately in bug 1139804 I mistakenly added the line that reads the content
disposition to a codepath that only runs if MIME type sniffing fails. It needs
to be pulled back out to the top level.
Attachment #8631380 - Flags: review?(tnikkel)
(Assignee)

Updated

4 years ago
Assignee: nobody → seth
Status: NEW → ASSIGNED
(Assignee)

Updated

4 years ago
Flags: needinfo?(seth)
Attachment #8631380 - Flags: review?(tnikkel) → review+
(Assignee)

Comment 10

4 years ago
Thanks for the quick review!
https://hg.mozilla.org/mozilla-central/rev/baad399c214a
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 42

Comment 13

4 years ago
Any possibility of uplift?

A user reported this on SuMo today: https://support.mozilla.org/questions/1071457

A temporary workaround is:

(1) right-click > View Image (or right-click > Ctrl+View Image for a new tab)
(2) Save Page As

Comment 14

4 years ago
Hi Seth, can you fill out the uplift requests? We want it for Beta/Aurora.
Flags: needinfo?(seth)
(Assignee)

Comment 15

4 years ago
Comment on attachment 8631380 [details] [diff] [review]
Read content disposition regardless of content type in imgRequest::PrepareForNewPart

Approval Request Comment
[Feature/regressing bug #]: 1139225
[User impact if declined]: Wrong filename displayed when right clicking on some images and choosing "Save Image As...".
[Describe test coverage new/current, TreeHerder]: On m-c for a day. We'd like a test for this, but I'm unfortunately not sure how to write one. I'll file a followup.
[Risks and why]: Low risk. The change is very small.
[String/UUID change made/needed]: None.
Flags: needinfo?(seth)
Attachment #8631380 - Flags: approval-mozilla-beta?
Attachment #8631380 - Flags: approval-mozilla-aurora?
(Assignee)

Updated

4 years ago
Blocks: 1182654

Comment 16

4 years ago
Comment on attachment 8631380 [details] [diff] [review]
Read content disposition regardless of content type in imgRequest::PrepareForNewPart

Approving uplift to Aurora and Beta because low risk/small change, has not caused issues on m-c.
Attachment #8631380 - Flags: approval-mozilla-beta?
Attachment #8631380 - Flags: approval-mozilla-beta+
Attachment #8631380 - Flags: approval-mozilla-aurora?
Attachment #8631380 - Flags: approval-mozilla-aurora+
On a side note, I've found that with e10s enabled this bug goes back much further, to September 2013 at least, if not earlier - on earlier Nightly builds, amongst other things the context menu doesn't work with e10s, so I can't really test.

In a current Nightly, Seth's patch has fixed the problem both with and without e10s enabled, so all is well.
Component: Untriaged → ImageLib
Product: Firefox → Core
Target Milestone: Firefox 42 → mozilla42
(Assignee)

Comment 20

4 years ago
(In reply to JanH from comment #17)
> On a side note, I've found that with e10s enabled this bug goes back much
> further, to September 2013 at least, if not earlier - on earlier Nightly
> builds, amongst other things the context menu doesn't work with e10s, so I
> can't really test.
> 
> In a current Nightly, Seth's patch has fixed the problem both with and
> without e10s enabled, so all is well.

I haven't investigated this issue specifically, but bug 1139804 was part of a series of patches that fixed *tons* of races in the image loading code. That's the sort of issue that e10s might tickle. So maybe there was a race related to content-disposition that bug 1139804 fixed, and that would've been the end of the issue, except that I made a mistake in bug 1139804 which was fixed here.
QA Whiteboard: [good first verify]
Reproduced with 42.0a1 (2015-07-03) (Build ID: 20150703030216) on Linux x64 by following comment 1's instruction!

The bug is fixed on Latest Nightly 42.0a1 (2015-07-15) (Build ID: 20150715030207),

Latest Aurora 41.0a2 (2015-07-15) (Build ID: 20150715004006) and

Latest Beta 40.0b3 (Build ID: 20150713153304)

Mozilla/5.0 (X11; Linux x86_64; rv:42.0) Gecko/20100101 Firefox/42.0
Mozilla/5.0 (X11; Linux x86_64; rv:41.0) Gecko/20100101 Firefox/41.0
Mozilla/5.0 (X11; Linux x86_64; rv:40.0) Gecko/20100101 Firefox/40.0
QA Whiteboard: [good first verify] → [good first verify][bugday-20150715]
Whiteboard: [bugday-20150715]
Reproduced with 42.0a1 (2015-07-03) (Build ID: 20150703030216) on windows 10 x64 by following comment 0 instruction!

The bug is fixed on Latest Nightly 42.0a1 (2015-07-21) (Build ID: 20150721004010),
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:42.0) Gecko/20100101 Firefox/42.0

Latest Aurora 41.0a2 (2015-07-15) (Build ID: 20150715004006),
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:41.0) Gecko/20100101 Firefox/41.0

Latest Beta 40.0b6 (Build ID: 20150720220238)
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:40.0) Gecko/20100101 Firefox/40.0

[bugday-20150722]
It is verified on Windows and Linux (Comment 21 and Comment 22), Marking it as verified!

Updated

4 years ago
Duplicate of this bug: 1192980

Comment 25

3 years ago
Hi,

I still experience this issue with Fixefox 49, it happens for instance on any "attachment" link on the Debian bug tracker, e.g.:

https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=704037;filename=piuparts_binfmt-misc_umount_fail.log;msg=5

from https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=704037

One could argue that they should use "Content-Disposition: attachment" instead of inline (and I'll propose that), but other browsers seem to be able to get the file name right when saving these links.

If you confirm the issue, can this bug be re-opened or should I file another one?

Thanks,
   Antonio

Comment 26

3 years ago
(In reply to Antonio Ospite from comment #25)
> Hi,
> 
> I still experience this issue with Fixefox 49, it happens for instance on
> any "attachment" link on the Debian bug tracker, e.g.:
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=704037;
> filename=piuparts_binfmt-misc_umount_fail.log;msg=5

WFM with FF49 or 52, see http://i.imgur.com/LkgmTpw.jpg
 
> If you confirm the issue, can this bug be re-opened or should I file another
> one?

Yes, this bug report is closed, you have to file a new one, please.

Comment 27

3 years ago
(In reply to Loic from comment #26)
> (In reply to Antonio Ospite from comment #25)
> [...]
> WFM with FF49 or 52, see http://i.imgur.com/LkgmTpw.jpg

I am on linux and the filename detection works when I left-click or middle-click on the link, but it doesn't if I right-click and choose "Save as".

> > If you confirm the issue, can this bug be re-opened or should I file another
> > one?
> 
> Yes, this bug report is closed, you have to file a new one, please.

OK, I will, thanks.
See Also: → 1452819
You need to log in before you can comment on or make changes to this bug.