1772569 - PDF attachments in gmail open in a new tab when clicking on the download icon that appears when hovering over the attachment.

Status: VERIFIED FIXED

(Firefox :: File Handling, defect, P2)

Description

[Yasmin S]

STR

1. Open an email in gmail that has a pdf attachment
2. Hover over the PDF attachment and click on download

Expected Result
PDF is downloaded.

Actual Result.
PDF opens in a new tab.

Note : Clicking on the download button in Chrome downloads the PDF. Clicking on the PDF Link opens it in a new tab. Download settings are set to open PDF in the browser.

Note: download settings are set to Open in Nightly for PDFs. Not sure if it is possible to override this specifically for the use case above ?

Comment 1

[Neil Deakin]

I don't think there is any way to do this. The pdf is just being sent with content-disposition:attachment and it should be displayed using the internal viewer.

Comment 2

[Neil Deakin]

Yes, I think the distinction here is that Chrome will only use its internal pdf viewer for pdf files that don't have content-disposition set, and will download them if that is set (or the download attribute on a link is set), whereas we use the internal viewer always. That is the design intended for bug 1719892 and friends.

But maybe there should be a means of allowing one the use the behaviour that other browsers have here, but I will leave that for someone else to determine.

Comment 3

[:Gijs (he/him)]

(In reply to Neil Deakin from comment #2)

Yes, I think the distinction here is that Chrome will only use its internal pdf viewer for pdf files that don't have content-disposition set, and will download them if that is set (or the download attribute on a link is set), whereas we use the internal viewer always. That is the design intended for bug 1719892 and friends.

But maybe there should be a means of allowing one the use the behaviour that other browsers have here, but I will leave that for someone else to determine.

Yeah, I think this is somewhat of a product call. There was extensive discussion from https://bugzilla.mozilla.org/show_bug.cgi?id=1756980#c58 onward.

The issue is that in some cases, the site gives a strong user expectation that the file will be downloaded in their UI (this happens in gmail, with the "download" icon etc). In others, that expectation is absent (it's just "here's a link or button", you click it, you have no strong expectation about the file being saved to disk or opened). That expectation is completely divorced from how the network request and markup is presented to the browser, ie the two cases look the same to the browser, despite looking very different to the user.

We're trying to give users a consistent experience - before, if people ticked the checkbox to "always open" downloaded files with a helper application, it was not honoured all the time. We fixed that, but also apply it to "view inline", so if PDFs (or images or...) are set to always show inline, we will honour that, even if the site (through <a download="foo.pdf"> links or Content-Disposition: attachment headers) indicates that the file "should" be downloaded.

I think we should discuss with a small group of folks and come back to this bug with a decision. I'll try to schedule something.

Comment 4

[:Gijs (he/him)]

Uh, I did not mean to mark this fixed.

Comment 6

[:Gijs (he/him)]

Talking to Romain, we'll switch the default for these attachment PDFs back to downloading rather than viewing inline, to be more compatible with other browsers. This will probably cause other bugreports in the opposite direction (ie people who want to see the PDF immediately rather than download it); we can only do one of the two things, so we have to accept that behaviour is suboptimal in one of the two cases... To give people choice, we'll add an about:config pref that controls this specific behaviour - this will likely supplant the use of the download improvement prefs for this feature.

Neil has kindly suggested he can work on this.

Comment 7

[:Gijs (he/him)]

Doc link for reference for some of the options we discussed

Comment 8

[Neil Deakin]

Attachment: Bug 1772569, add a preference so that pdf files sent as attachments can be opened either inline or download, and default to downloaded, r=gijs

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/77e7d5bff788
add a preference so that pdf files sent as attachments can be opened either inline or download, and default to downloaded, r=Gijs

Comment 10

[bszekely]

https://hg.mozilla.org/mozilla-central/rev/77e7d5bff788

Comment 11

[Neil Deakin]

Comment on attachment 9282708 [details]
Bug 1772569, add a preference so that pdf files sent as attachments can be opened either inline or download, and default to downloaded, r=gijs

Beta/Release Uplift Approval Request

• User impact if declined: This bug reverts some pdf downloading behaviour so that attachments are downloaded instead of opened inline, better matching the behaviour of other browsers.

Also, considering that bug 1762868 is in 103, it means that some pdfs would download in 102, open inline in 103, then download again in 104. It would be good to avoid this repeated change in behaviour.

• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): It reverts to a previous behaviour for pdf files only, and a preference is added to switch between both behaviours.
• String changes made/needed: No
• Is Android affected?: Unknown

Comment 12

[Donal Meehan [:dmeehan]]

Comment on attachment 9282708 [details]
Bug 1772569, add a preference so that pdf files sent as attachments can be opened either inline or download, and default to downloaded, r=gijs

Approved for 103.0b8, thanks.

Comment 13

[Donal Meehan [:dmeehan]]

https://hg.mozilla.org/releases/mozilla-beta/rev/3a6841dda2a9

Comment 14

[Daniel Bodea [:danibodea]]

The issue reproduces in Nightly from 2022-06-15 (the PDF is only downloaded) and the fix is confirmed in Nightly v104.0a1 from 2022-07-13 and Beta v103.0b8 on Windows 10, Ubuntu 22 (wayland and xwayland) and Mac OS 11 (the PDF is BOTH opened in a new tab and downloaded in the default download folder).

Comment 15

[jscher2000]

If I understand what has changed here, with the default action of "Open in Firefox", a PDF served with Content-Disposition: attachment --

• in Firefox 102.0.2 -- opens in a new tab as web content
• in Firefox 103b09 -- opens in a new tab from disk after being saved to the download folder

It is expected/intended that the PDF still opens in a tab after this change?

Comment 16

[:Gijs (he/him)]

(In reply to jscher2000 from comment #15)

If I understand what has changed here, with the default action of "Open in Firefox", a PDF served with Content-Disposition: attachment --

• in Firefox 102.0.2 -- opens in a new tab as web content
• in Firefox 103b09 -- opens in a new tab from disk after being saved to the download folder

It is expected/intended that the PDF still opens in a tab after this change?

That's not what I expected. Neil and Romain, can you check?

Comment 17

[Neil Deakin]

That is what happens, yes. I'm pretty sure I asked about this somewhere when implementing it but can't seem to find it.

Two requests are made, one for the http url which gets saved to disk, and then a second request with a different stack for the file url. I don't know where this happens, or what triggers it. Otherwise, we could block opening the file url in a tab.

Comment 18

[:Gijs (he/him)]

(In reply to Neil Deakin from comment #17)

That is what happens, yes. I'm pretty sure I asked about this somewhere when implementing it but can't seem to find it.

Two requests are made, one for the http url which gets saved to disk, and then a second request with a different stack for the file url. I don't know where this happens, or what triggers it. Otherwise, we could block opening the file url in a tab.

we hit this: https://searchfox.org/mozilla-central/rev/f6a2ef2f028b8f1eb82fa5dc5cb1e39a3baa8feb/toolkit/components/downloads/DownloadCore.jsm#621-622

because we hit this: https://searchfox.org/mozilla-central/rev/f6a2ef2f028b8f1eb82fa5dc5cb1e39a3baa8feb/toolkit/components/downloads/DownloadLegacy.jsm#359-361

I'm still not sure what the desired behaviour is (so would be useful for Romain to chime in about that). It would also be useful to check, for both this gmail case and for a more controlled testcase (cf. https://mime.ty.ax/ might help) what we did in, say, 96 or 94 (with download improvements off), what we did in 102, and what we're doing now. Because AIUI we still used to download for gmail, perhaps without prompting once we enabled download improvements, perhaps because they send application/octet-stream as the mimetype, or something? Maybe I'm misremembering - the... let's say unhappiness... in bug 1756980 was that we no longer prompted, but also that we "overwrote" the tab. Now we're not overwriting the tab, and we are downloading - but we're also still opening. We could avoid doing the opening, by making adjustments to the code cited above, but I dunno if that's actually what we want... still, given my hazy recollection (thanks covid/heatwave), it would be really useful to confirm what exactly changed here.

Comment 19

[Romain Testard [:RT]]

We had agreed to download to disk for content-disposition: attachment and <a download> links. I don't think we clarified the implications on opening the pdf in the new tab. We want to keep opening the downloaded pdf in a new tab by default:

• download to disk for content-disposition: attachment and <a download> links
• keep opening the pdf file on a new tab

In terms of the rationale to keep opening the pdf file in a new tab:

• consistency with current behavior where we open
• consistency with Chrome that downloads and opens the pdf file in a new tab if it's set as default handler for pdf
• this should align with most user expectations where downloading a file is likely followed-up by an open action
  We expect that a minority of users won't want the pdf file to open in a new tab when downloaded, in this case they can go to about:preferences and set the "pdf" content type to "Save File"

Comment 20

[Gonzalo HIGUERA DÍAZ]

I don't know what type of settings are used when clicking on the download icon which appears when hovering over an attachment in Gmail. The reasons for which when performing that action I would expect the file to be downloaded and not opened and displayed in a new tab are the following (tested on macOS 10.14 using a guest profile):

• As I mentioned in #1769214, for consistency within Firefox, so that the handling of PDF, WEBP and similar files is the same as GIF, PNG and similar files, which in this use case are just downloaded and not opened.
• For consistency with Chrome (both stable 103.0.5060.114 and Canary 105.0.5190.0, confirmed to have "Open PDFs in Chrome" selected in Privacy and security -> Site settings -> Additional content settings), which just download the files without opening them.

For completeness I will also mention that:

• Safari 15.5 (15613.2.7.1.9, 15613) behaves differently: it downloads all file types I previously named and then opens them in Preview (again, on macOS 10.14 using a guest profile).
• HTML attachments in all mentioned browsers are saved and not opened in any way when following the use case.

Comment 21

[Brad Greco]

I found it rather surprising that the download attribute would cause the PDF to open in a new tab as well as downloading, since no other file type works that way. I would expect the download attribute to only trigger a download, not a new tab.

Comment 22

[Neil Deakin]

In Firefox 94, if I click on Download on a Gmail attachment:

• PDF set to 'Open in Firefox' -> the save prompt appears. If I choose 'Open with Firefox', the pdf is saved, the download panel opens, and the downloaded 'file://' pdf opens in a new tab. If I choose to 'Open with Preview', the pdf is saved, and opened with Preview. If I choose to save, the file is downloaded and not otherwise opened.
• PDF set to 'Always Ask', the same behaviour as 'Open in Firefox' occurs.
• PDF set to 'Save', the file is downloaded and not opened.

The same thing happens in 103, but when PDF is set to 'Open in Firefox', the prompt doesn't appear and the PDF is directly downloaded, and the downloaded 'file://' pdf opens in a new tab.

So I don't think there is any surprising difference between the old and new behaviour.

Comment 23

[aR Gon]

Sorry to muddy the waters here...

I am not accustomed to participating in product design decisions. So, I will start by apologizing in advance If my input is not appropriate and/or should be placed somewhere else.
The details are a bit over my head with my current knowledge. So, I may not fully understand the issue/difficulties. Please keeps that in mind if you choose to respond directly to me.

Okay, to my input:

As a user:
When I download something, I expect the file to be handled in accordance to my settings. In my case, I choose to have a bit of structure in my storage. So, in the browsers that I use, I choose the "Always Ask" option.

With this setting chosen, what I expect is:

• When downloading any file: I'm asked where to save the file (defaulting to the last directory previously chosen)

That's it.

If I want to open that file semi-immediately afterward, then I go to the download monitoring 'thingy' (whether at the bottom of the page or in the download manager) and I choose to "Open". If I want to rename/move/"something else to" the file, then I go to the 'thingy' and chose "Show in folder" and I am now there to do what I want.

I realize that it is an Over-Simplification and, most likely, a lot more complicated that.

What I am saying is I see that downloading a file and using a file are independent (decoupled?).

I get that (at least I think it's something similar to this) to view a web page, dozens, if not hundreds, of files are needed to view it as intended. And, all those files are downloaded somewhere. No, I don't want to be asked about these. I think that these, or many of these, are put somewhere in a "cache?". And, as a user, I can 'Clean up'/remove these files in general through a browser's 'Settings' somewhere.

So, when I click on a link, I am choosing to "view" that site/page/file. However, if the link is a "Download" link, I expect the browser to ask me where to download it. And, if the browser decides to "show" me the file, such as a .pdf, when I wanted to "Download"/save it, no problem, I then choose to Download it and we are back to "asking where".

What is annoying to me, is if the browser ignores the configuration that I have chosen. In this case, Downloads without "asking". Why is that annoying? Because, now I have to find the damned file. Over the years, I have learned to check the "Downloads" folder. But, if it isn't there, then I need to open my browser settings and find out where the download folder is pointing to-then back to file system to get to that folder. If it isn't there, then I'm not sure (and probably very frustrated).

I had opened a bug report, I don't remember the exact circumstances. I do know that Firefox was not asking me where to download the file. It didn't matter if it opened in a new tab (If it did open a new tab, I would have just gone to that tab to download it).

What I remember is that it just kept not asking me and placing it in the "default" directory.

I guess Gijs is right, you will get complaints either way. I will say, however, with other browsers, I don't seem to have "complain" about where the file is downloaded. In addition, I don't seem to have to configure an "additional" setting. And more specifically, having this "additional" setting loose the functionality of displaying a .pdf *automatically.

*displaying .pdf automatically = I think that is the result to setting this "additional" setting. If not, please ignore the last sentence - That would be my misunderstanding. I have not tested this.

I want to thank everyone involved with developing/maintaining Firefox! I know that there are tough decision to be made and the result will most likely NOT please every user. So, please do not take my comment as negative or an attack. It is just feedback.

Also, if I am not understanding the discussion/issue/concern and my comments don't make sense or even apply, I apologize. Again, a lot of this was beyond my current level of knowledge.

Comment 24

[aR Gon]

Um, I do not remember making that section Bold. Sorry! Not sure how to change that. I am not upset at all, I was just stating an annoyance.

Comment 25

[jscher2000]

(In reply to aR Gon from comment #23)

As a user:
When I download something, I expect the file to be handled in accordance to my settings. In my case, I choose to have a bit of structure in my storage. So, in the browsers that I use, I choose the "Always Ask" option.

With this setting chosen, what I expect is:

• When downloading any file: I'm asked where to save the file (defaulting to the last directory previously chosen)

That's it.

Firefox has multiple interoperating "Always ask" selections on the Settings page.

(1) If you choose Save File, then the checkbox below the "Save files to:" option determines whether Firefox saves a file automatically, or asks you where to save the file.

But how do you select to save a file?

(2) The Applications list indicates what Firefox will do when asked to open various known content types. For PDFs, the default selection is "Open in Firefox". If you want to be prompted where to save the file, you need to change this to "Save file". If you want to choose whether to immediately open OR save the file, you need to change this to "Always ask". (We can have a separate discussion about where files are auto-saved if you choose Open with... in that dialog.)

What if the content type isn't listed or Firefox doesn't recognize it as being listed?

This can be caused by a server assigning a novel content type (e.g., application/x-force-download) or using a generic content type. So for that:

(3) Firefox should save those files by default, and should follow your selection under #1. If you want to choose whether to immediately open OR save the file, below the Applications list, there is a selector for what to do with content types that do not have prescribed handling. Choose "Ask whether to open or save" to bypass automatic saving. (That is similar to the pre-Firefox 98 behavior.)

Obviously it would be amazing if a wizard could guide you through these various selections to achieve your precise intent, but we don't have that so it's more of a support issue explaining how to make it work for you.

Does that make sense?