Closed Bug 773942 Opened 9 years ago Closed 7 months ago

Should be able to view PDFs even if the response HTTP headers include Content-Disposition:attachment

Categories

(Firefox :: PDF Viewer, defect)

x86_64
Windows 7
defect
Not set
normal

Tracking

()

VERIFIED FIXED
Firefox 78
Tracking Status
relnote-firefox --- 78+
firefox78 --- verified

People

(Reporter: Unfocused, Assigned: jaws)

References

(Depends on 2 open bugs, Blocks 2 open bugs, Regressed 1 open bug)

Details

(Whiteboard: [pdfjs-c-feature])

Attachments

(11 files, 1 obsolete file)

47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
2.17 KB, text/plain
chutten|PTO
: data-review+
Details
47 bytes, text/x-phabricator-request
Details | Review
15.56 KB, image/png
Details
Some sites serve PDFs with the following HTTP header:
  Content-Disposition: attachment; filename="whatever.pdf"

Which is meant to signal to the browser that it should offer to save the file (with the specified filename), rather than try displaying it. But now we have a built-in PDF viewer, I should be able to decide for myself whether I want view it or save it.
"Content-Disposition: attachment" is used both as a UI hint (the user probably wants to save the file) and as a security mechanism (origin isolation). Overriding the former is cool, but overriding the latter is not.

I don't know much about PDFs.  Depending on their use of scripts and subresources, it might not be safe to fix this without first fixing ... whatever it is that bug 57342 secretly depends on.
Whiteboard: [pdfjs-c-feature]
Duplicate of this bug: 823848
PDF.js will display PDFs in the isolated origin (resource://pdf.js).
This bug is particularly significant to users of Google Docs aka Google Drive. It seems to prevent me from opening pdfs served from the site. The only way to access them is through an extremely fiddly work-around. If so, it will affect a lot of users. 

Steps to reproduce:

1. In FF 21.0 go to docs.google.com and create a text document using the word processor.
2. In the document area click the Print button (not the Firefox print command).
3. The dialog "What should Firefox do with this file" opens. 
4. Browse to find the required program. You have to hunt for it in "Program Files" because it is not among the offered choices.
5. Check "Do this automatically for files like this from now on".
6. File opens in Adobe Reader this time.
7. Try clicking print button again.

Actual results:
Firefox has forgotten the file association and you have to do it all over again. It is particularly annoying because Adobe Reader is not among the offered choices. You have to hunt for it every time in "Program Files".

Expected results:
Firefox should open the document in Adobe Reader.

Investigation: Firebug shows that Google is serving the pdf with the following headers
  Content-Disposition: attachment;filename="Myfile.pdf"
  Content-Type:application/pdf; charset=utf-8
  
Background: This is fundamental to the design of Google Docs (aka Google Drive). You edit your document in the cloud. When you want to print it, Google serves it to you as a pdf which opens in your local Adobe Reader. This means you can use the full range of printing options available on your local machine. Note that you don't want it to open in your brower with pdf.js or a plugin. This must be affecting lots of people. For me it makes Google Docs almost unusable. It might be a reason to switch to Chrome. 
  
According to comment 2 Firefox won't open the pdf for security reasons. I can't see why it would be a problem to open it in a separate application like Adobe Reader. If there is a security issue, there just needs to be a simple way in Firefox to click through.
Depends on: 453455
(In reply to Blair McBride [:Unfocused] from comment #0)

> But now
> we have a built-in PDF viewer, I should be able to decide for myself whether
> I want view it or save it.

I fully agree.

The same holds for images. [Yes, some Web servers serve images with "attachment" header...] 

See also : bug 801786, for images.
Duplicate of this bug: 1128263
Duplicate of this bug: 1351421
Duplicate of this bug: 1559877
Duplicate of this bug: 1632295
Assignee: nobody → jaws
Status: NEW → ASSIGNED
Duplicate of this bug: 819952

This is currently preffed off behind the "browser.helperApps.showOpenOptionForPdfJS" pref.

Comment on attachment 9143827 [details]
Bug 773942 - Rename 'Preview in Firefox' to 'Open in Firefox' since 'preview' projects limited capabilities. r?Gijs

Revision D72775 was moved to bug 1581383. Setting attachment 9143827 [details] to obsolete.

Attachment #9143827 - Attachment is obsolete: true
Attachment #9146045 - Flags: data-review?(chutten)
Comment on attachment 9146045 [details]
Telemetry data review request

DATA COLLECTION REVIEW RESPONSE:

    Is there or will there be documentation that describes the schema for the ultimate data set available publicly, complete and accurate?

Yes. This collection is Telemetry so is documented in its definitions file [Scalars.yaml](https://hg.mozilla.org/mozilla-central/file/tip/toolkit/components/telemetry/Scalars.yaml) and the [Probe Dictionary](https://telemetry.mozilla.org/probe-dictionary/).

    Is there a control mechanism that allows the user to turn the data collection on and off?

Yes. This collection is Telemetry so can be controlled through Firefox's Preferences.

    If the request is for permanent data collection, is there someone who will monitor the data over time?

Yes, Jared Wein is responsible.

    Using the category system of data types on the Mozilla wiki, what collection type of data do the requested measurements fall under?

Category 2, Interaction.

    Is the data collection request for default-on or default-off?

Default on for all channels.

    Does the instrumentation include the addition of any new identifiers?

No.

    Is the data collection covered by the existing Firefox privacy notice?

Yes.

    Does there need to be a check-in in the future to determine whether to renew the data?

No. This collection is permanent.

---
Result: datareview+
Attachment #9146045 - Flags: data-review?(chutten) → data-review+
Pushed by jwein@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/97f3b96b6be0
Remove some dead code and an old hack that isn't necessary anymore. r=Gijs
https://hg.mozilla.org/integration/autoland/rev/f4df0a553bc0
Add a radio button to open the PDF in Firefox. r=Gijs,flod,fluent-reviewers
https://hg.mozilla.org/integration/autoland/rev/286e1be9dc46
Open PDFs using pdf.js in a new tab when the Preview option is selected from the Unknown Content Type dialog. r=Gijs
https://hg.mozilla.org/integration/autoland/rev/dfedbeeaec66
Use a generic string for the PDF description since it is not necessarily tied to the default handler. r=Gijs
https://hg.mozilla.org/integration/autoland/rev/7da06239ccfb
Use the browsingContext to open the new tab with correct userContextId, private-ness, and ownerTab. r=Gijs
https://hg.mozilla.org/integration/autoland/rev/df062e14287b
Hide the 'Open with Firefox' option if the download is started from the download button in pdf.js. r=Gijs
https://hg.mozilla.org/integration/autoland/rev/ee0ecad5e90a
Add tests that cover the generic PDF description and the 'open with (internal handler)' option of the Unknown Content Type dialog. r=Gijs
https://hg.mozilla.org/integration/autoland/rev/27e9fe03a549
Add telemetry to track which PDF viewer was used from the Unknown Content Type dialog. r=Gijs
https://hg.mozilla.org/integration/autoland/rev/6fb0f25b2f5d
Create a new init method in nsITransfer that accepts a BrowsingContext and if the download should be handled internally for backwards-compat. r=Gijs
Flags: needinfo?(jaws)
Pushed by jwein@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/f9b9a4e581a0
Remove some dead code and an old hack that isn't necessary anymore. r=Gijs
https://hg.mozilla.org/integration/autoland/rev/5946b607dbdd
Add a radio button to open the PDF in Firefox. r=Gijs,flod,fluent-reviewers
https://hg.mozilla.org/integration/autoland/rev/8a2cbedfce0c
Open PDFs using pdf.js in a new tab when the Preview option is selected from the Unknown Content Type dialog. r=Gijs
https://hg.mozilla.org/integration/autoland/rev/f25facacb6f6
Use a generic string for the PDF description since it is not necessarily tied to the default handler. r=Gijs
https://hg.mozilla.org/integration/autoland/rev/5d6bba3a46e9
Use the browsingContext to open the new tab with correct userContextId, private-ness, and ownerTab. r=Gijs
https://hg.mozilla.org/integration/autoland/rev/0f4b6b00a499
Hide the 'Open with Firefox' option if the download is started from the download button in pdf.js. r=Gijs
https://hg.mozilla.org/integration/autoland/rev/12e6b6ce2417
Add tests that cover the generic PDF description and the 'open with (internal handler)' option of the Unknown Content Type dialog. r=Gijs
https://hg.mozilla.org/integration/autoland/rev/e41771c58282
Add telemetry to track which PDF viewer was used from the Unknown Content Type dialog. r=Gijs
https://hg.mozilla.org/integration/autoland/rev/882de07e4cbe
Create a new init method in nsITransfer that accepts a BrowsingContext and if the download should be handled internally for backwards-compat. r=Gijs
Attached image firefox_xIygp4bfaL.png

How it looks like in the download dialog.

Regressions: 1638683

(In reply to kernp25 from comment #28)

Created attachment 9149672 [details]
firefox_xIygp4bfaL.png

How it looks like in the download dialog.

Thanks, yes that is generally how it should look though I see it is not localized and appears in English. This is expected on Nightly builds as the localizers have not had a chance to translate the text yet. Sometime during Nightly or Beta this text will get translated. Thank you for helping test the feature!

Depends on: 1638693
Regressions: 1640589

Release Note Request (optional, but appreciated)
[Why is this notable]: The default option for PDFs that are downloaded as an attachment is now set to open the PDF directly in Firefox.
[Affects Firefox for Android]: no
[Suggested wording]: PDF downloads now show an option to open the PDF directly in Firefox.
[Links (documentation, blog post, etc)]: n/a, please flag me if you would like some help creating some documentation or a blog post.

relnote-firefox: --- → ?

Added to the 78.0beta release notes.

Verified fixed with Fx 78.0b2 across platforms - Windows 10 64bit, macOS 10.15 and Ubuntu 18.04.

Status: RESOLVED → VERIFIED
Duplicate of this bug: 1122340
See Also: → 1657796
Regressions: 1659008
See Also: → 1672583
Depends on: 1672384
Blocks: 1672384
No longer depends on: 1672384
You need to log in before you can comment on or make changes to this bug.