1407846 - Save file dialog no longer appears for PDF's

Status: NEW

(Firefox :: File Handling, defect, P3)

Description

[Brendan Dahl [:bdahl]]

I did a bisect and it looks like this was a regression back from bug 1287664.

STR:
1. Open https://github.com/armenzg/firefox-code-coverage-frontend/raw/7b67f2e948de94b7f837ba9a7c57a31e810d9fe7/docs/Prototype%20Instructions.pdf

Expected:
The save file as dialog should appear.

Actual:
The file is automatically downloaded with no user prompt.


FWIW: Other file types with content-disposition of attachment seem to work fine, just PDF's have issues.

Comment 1

[Brendan Dahl [:bdahl]]

Any thoughts on this?

Comment 2

[Alphan Chen [:alchen]]

Could you check the setting of preference? (Always ask you where to save files)
Preferences->General->Files and Application

I don't have the symptom if "Always ask you where to save files" is set.

Comment 3

[Brendan Dahl [:bdahl]]

All the testing above was done with a clean profile. I bisected on a windows and linux box and got the same results that before and after your patch the behavior changed.

When I looked at this further, the above PDF doesn't use content-disposition (raw pdfs from github use to a year ago). Strangely, I wasn't able to reproduce the issue with a locally hosted PDF. I tried using the same file type and using some other similar headers (X-Content-Type-Options: nosniff) as the above PDF, but the save dialog always comes up for me. Maybe there's something timing dependent?

The above PDF's headers
Access-Control-Allow-Origin: https://render.githubusercontent.com
Age: 0
Cache-Control: no-cache
Content-Length: 213
Content-Security-Policy: default-src 'none'; base-uri '…inline' assets-cdn.github.com
Content-Type: text/html; charset=utf-8
Date: Thu, 12 Oct 2017 18:19:51 GMT
Location: https://raw.githubusercontent.…/Prototype%20Instructions.pdf
Public-Key-Pins: max-age=5184000; pin-sha256="W…spMnox7A="; includeSubDomains
Server: GitHub.com
Status: 302 Found
Strict-Transport-Security: max-age=31536000; includeSubdomains; preload
Vary: X-PJAX, Accept-Encoding
X-Content-Type-Options: nosniff
X-Frame-Options: deny
X-GitHub-Request-Id: 61B4:1D379:210B18AA:31641D42:59DFB247
X-RateLimit-Limit: 100
X-RateLimit-Remaining: 99
X-RateLimit-Reset: 1507832691
X-Runtime: 0.030943
X-Runtime-rack: 0.034958
X-UA-Compatible: IE=Edge,chrome=1
X-XSS-Protection: 1; mode=block

Comment 4

[Alphan Chen [:alchen]]

Hi Paolo,
any idea about this?
I have no idea about the dependency between HandlerService and save file dialog.

Comment 5

[:Paolo Amadini]

If I understand the prerequisites, the PDF file must be served as "text/html" without the "Content-Disposition" header.

I don't know which part of bug 1287664 could have caused this regression. We don't have a team working on file handling right now, and this isn't a severe regression, which means that this issue is more likely to get attention in the related bug 1406126 in the PDF Viewer component. If you have time to debug or investigate, I'd be interested in the results.

Comment 6

[Firefox Bug Husbandry Bot]

https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Move_fix-optionals

Comment 7

[Brendan Dahl [:bdahl]]

I missed something when trying to reproduce locally. The first HTTP response is actually a redirect. The second response has a header with Content-Type: application/octet-stream