Closed Bug 1180126 Opened 9 years ago Closed 9 years ago

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

Categories

(Core :: Graphics: ImageLib, defect)

39 Branch
defect
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla42
Tracking Status
firefox38 --- unaffected
firefox38.0.5 --- unaffected
firefox39 --- affected
firefox40 + verified
firefox41 + verified
firefox42 + verified
firefox-esr31 --- unaffected
firefox-esr38 --- unaffected

People

(Reporter: firefoxbugs, Assigned: seth)

References

(Blocks 1 open bug)

Details

(Keywords: regression, Whiteboard: [bugday-20150715])

Attachments

(2 files)

Attached 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
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
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
Via local build
Last Good: fcaed7860ea4
First Bad: 3f5eae4fac0f+f687743cc499

Regressed by: Bug 1139225
Blocks: 1139225
No longer blocks: 1139804
[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.
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: nobody → seth
Status: NEW → ASSIGNED
Flags: needinfo?(seth)
Attachment #8631380 - Flags: review?(tnikkel) → review+
Thanks for the quick review!
https://hg.mozilla.org/mozilla-central/rev/baad399c214a
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 42
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
Hi Seth, can you fill out the uplift requests? We want it for Beta/Aurora.
Flags: needinfo?(seth)
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?
Blocks: 1182654
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
(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!
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
(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.
(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.