Closed Bug 1811830 Opened 2 years ago Closed 2 years ago

Treat PDF like browser native file types

Categories

(Firefox :: File Handling, enhancement)

Product:
Firefox
Component:
File Handling
Type:
enhancement

Tracking

()

Status:
VERIFIED FIXED
Milestone:
119 Branch
Tracking Flags:
Tracking Status
firefox-esr115 118+ verified
firefox118 --- verified
firefox119 --- verified

People

(Reporter: emk, Assigned: mkaply)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

Bug 1811830 - Add a preference to force downloading of attachments. r?Gijs,kershaw
48 bytes, text/x-phabricator-request
pascalc
: approval-mozilla-beta+
pascalc
: approval-mozilla-esr115+
Details | Review

Steps to reproduce:

  1. Open http://emk.name/test/bug1790641.html.
  2. Click all links.

Actual result:
Text / View and PDF / View will open the file in Firefox.
Text / Download, Zip / View, and Zip / Download will save the file to the download folder.
PDF / Download will download the file then open.

Expected result:
PDF / Download should be treated just like Text / Download.

Chrome works as expected.

(In reply to :Gijs (he/him) from bug 1790641 comment #28)

If you feel strongly that we should differentiate between those two "download" hints from the website, you can file a separate bug - it's orthogonal to the private window issue that this bug is about. I don't see us wholesale reverting bug 453455.

To be clear, I do not want such behavior.

It otherwise works for txt only because that is a mimetype (text/plain) that the browser can render natively. It "works" for all such types, but no other ones. As a result, it doesn't work for PDF because that's rendered by PDF.js, not the browser (it's not treated the same as HTML/txt/images/media which the browser can render itself). So it's less that we did something different for PDF, and more that we [still] treat PDF like "all the other files" in this respect.

It is an implementation detail. From users perspective, Firefox can render PDF in the browser tab just like native file types. In Settings > General > Applications, PDF has the "Open in Firefox" choice just like native file types. But the behavior of the option is different from other native types, different from Chrome. It is counterintuitive IMO.

Yes, it would potentially help some users with this issue as regards PDFs, but would not help for any other filetypes and would not help cases where the website choice ("download" vs "show") isn't the one the user wants.

No other external file types have the "Open in Firefox" option. Since we dropped support for third-party plug-ins, only PDF is special.

(In reply to Masatoshi Kimura [:emk] from comment #1)

No other external file types have the "Open in Firefox" option. Since we dropped support for third-party plug-ins, only PDF is special.

AVIF and XML and SVG and WEBP do the same thing as PDF, right?

Flags: needinfo?(VYV03354)

(In reply to :Gijs (he/him) from comment #2)

(In reply to Masatoshi Kimura [:emk] from comment #1)

No other external file types have the "Open in Firefox" option. Since we dropped support for third-party plug-ins, only PDF is special.

AVIF and XML and SVG and WEBP do the same thing as PDF, right?

No. All native file types (Text, SVG, PNG, WebP, and AVIF) have consistent behaviors. All external file types (such as Zip) also have consistent behaviors except PDF. Only PDF has the inconsistent behavior. I added test files and test matrix to my test case.

Flags: needinfo?(VYV03354)

(In reply to Masatoshi Kimura [:emk] from comment #3)

(In reply to :Gijs (he/him) from comment #2)

(In reply to Masatoshi Kimura [:emk] from comment #1)

No other external file types have the "Open in Firefox" option. Since we dropped support for third-party plug-ins, only PDF is special.

AVIF and XML and SVG and WEBP do the same thing as PDF, right?

No. All native file types (Text, SVG, PNG, WebP, and AVIF) have consistent behaviors. All external file types (such as Zip) also have consistent behaviors except PDF. Only PDF has the inconsistent behavior. I added test files and test matrix to my test case.

Hm. I guess you're comparing the results when action is set to "Save File" or "Use external app". But per your test matrix, PDF/SVG/PNG/WebP/AVIF behave the same as PDF if set to "Open in Firefox" in the settings (which, fwiw, is possible for me for XML files. I don't know why the option wouldn't be there for you... on a clean profile it's set to "Save File", but "Open in Firefox" is available in the dropdown.)

(In reply to :Gijs (he/him) from comment #4)

Hm. I guess you're comparing the results when action is set to "Save File" or "Use external app". But per your test matrix, PDF/SVG/PNG/WebP/AVIF behave the same as PDF if set to "Open in Firefox" in the settings

Yes. PDF behaves like native types when "Open in Firefox" is chosen and behaves like external types when "Save File" or "Use external app" is chosen. It looks inconsistent to me.

(which, fwiw, is possible for me for XML files. I don't know why the option wouldn't be there for you... on a clean profile it's set to "Save File", but "Open in Firefox" is available in the dropdown.)

When I create a new profile, XML has "Open in Firefox" option, but it has no effect. When I download a XML file and check "Always Open in Internet Explorer" from the context menu on Download Manager, "Extensible Markup Language (XML) (application/xml)" entry is added and the existing entry is renamed to "Extensible Markup Language (XML) (text/xml)". I thought the latter is the existing entry because it has "Open in Firefox" option and it has no effect. The former does not have "Open in Firefox", but other options work. I guess this bug about XML is specific to Windows.

I actually added a text/xml test case. The previous test case was the same as application/xml one. So it's natural that the text/xml option was ignored. But "Open in Firefox" should be available for application/xml files. I'll file another bug about this problem.

(In reply to Masatoshi Kimura [:emk] from comment #6)

I actually added a text/xml test case. The previous test case was the same as application/xml one. So it's natural that the text/xml option was ignored. But "Open in Firefox" should be available for application/xml files. I'll file another bug about this problem.

Filed bug 1821796.

Duplicate of this bug: 1845943

Hi Gijs,

We are switching from 1845943.
Following your advice, our web-extension Proof of Concept is currently not successful (avoiding the pdf to be opened or closing the viewer after downloading). Anyway, any suggestions would be helpful.

We’re not able to identify the context and the applications’ requests sometime integrated in javascript functions. Also we’re not sure to be able to prevent the pdf viewer window to open or force it to close.

We’ll try to get in touch with Mertens Peetz that developed the « no pdf extension » and share our business case.

Short term change request :

The « browser.download.improvements_to_download_panel » preference recently disabled used to detect a download request even when the « open in firefox » was setted for pdf files.

Could you please reactive this pref or duplicate, implementing a simple process : not viewing pdf files in firefox after download, without questioning the user (no dialog box).

Benefits for our 5000 users :

  • Prevent from contract subscription process errors as the FF Views can’t be used in this case.

  • Productivity issues in claims management.

  • Timeframe : We’re supposed to deploy FF115 by the end of septembre. The only way to maintain security fixes benefits. We can try to negociate a complementary delay with business units, depending on your answer.

Benefits for the Firefox Community :

Time saving for Gmail, outlook, sharepoint (and so on…) users that don’t need to vizualize when downloading.

Download process simplification, similar to other web browsers.
Thanks a lot

Assignee: nobody → mozilla
Status: NEW → ASSIGNED

[Tracking Requested - why for this release]: Customer needs this for rollout.

tracking-firefox-esr115: --- → ?
Blocks: 1851822
Pushed by mozilla@kaply.com: https://hg.mozilla.org/integration/autoland/rev/1bb2685819d4 Add a preference to force downloading of attachments. r=Gijs

https://hg.mozilla.org/mozilla-central/rev/1bb2685819d4

Status: ASSIGNED → RESOLVED
Closed: 2 years ago
status-firefox119: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 119 Branch

Mike, do you want to request uplift to beta and ESR?

Flags: needinfo?(mozilla)

Comment on attachment 9351235 [details]
Bug 1811830 - Add a preference to force downloading of attachments. r?Gijs,kershaw

Beta/Release Uplift Approval Request

  • User impact if declined: Downloads don't work for this particular case
  • Is this code covered by automated tests?: No
  • Has the fix been verified in Nightly?: Yes
  • Needs manual test from QE?: Yes
  • If yes, steps to reproduce: Using testcase in bug, flip pref browser.download.force_save_internally_handled_attachments and verify that when clicking the download link for the PDF, it downloads instead of opens in firefox.
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): No effect if pref is not set.
  • String changes made/needed:
  • Is Android affected?: Yes

ESR Uplift Approval Request

  • If this is not a sec:{high,crit} bug, please state case for ESR consideration: Needed for ESR 115 migration for customer
  • User impact if declined: Downloads don't work for this particular case
  • Fix Landed on Version: 119
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): No effect if pref is not set.
Flags: needinfo?(mozilla)
Attachment #9351235 - Flags: approval-mozilla-esr115?
Attachment #9351235 - Flags: approval-mozilla-beta?
Flags: qe-verify+

Comment on attachment 9351235 [details]
Bug 1811830 - Add a preference to force downloading of attachments. r?Gijs,kershaw

Approved for 118.0b6, thanks.

Attachment #9351235 - Flags: approval-mozilla-beta? → approval-mozilla-beta+

Comment on attachment 9351235 [details]
Bug 1811830 - Add a preference to force downloading of attachments. r?Gijs,kershaw

Approved for ESR 115.3, thanks.

Attachment #9351235 - Flags: approval-mozilla-esr115? → approval-mozilla-esr115+
QA Whiteboard: [qa-triaged]

I have reproduced this issue using Firefox 111.0a1 (2023.01.23) on Windows 10.
I can confirm this issue is fixed, I verified using Firefox 119.0a1, 118.0b7 on Windows 10, Ubuntu 22 and macOS 12, setting the pref browser.download.force_save_internally_handled_attachments to true, accessing the test page then clicking on download link for the PDF, it downloads instead of opens in Firefox and no effect if pref is not set.

status-firefox118: fixed → verified
status-firefox119: fixed → verified

I can confirm this issue is fixed, I verified using Firefox 115.3.0esr on Windows 10, Ubuntu 22 and macOS 12.

Status: RESOLVED → VERIFIED
status-firefox-esr115: fixed → verified
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: