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.

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.

(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.

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+

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

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