1655974 - PDF Handling: When user manually selects "Open in Firefox", Firefox downloads and then opens.

Status: RESOLVED INVALID

(Firefox :: PDF Viewer, defect)

Description

[Andy Mercer]

Attachment: FirefoxVsEdgePDFs.mp4

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Firefox/78.0

Steps to reproduce:

1. Open browser and navigate to:

https://www.functionaldevices.com/support/downloads/datasheet-generator/?SKU=RIBU1C

2. Select option to Open in Firefox

Actual results:

Firefox downloads the PDF and then opens from user's local app data folder.

Expected results:

Firefox should open the PDF without downloading at all, and without changing the URL. (This is how Firefox used to handle this situation, and how Chrome and Edge both handle it)

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Comment 2

[:Gijs (out for now; he/him)]

I opened the URL in comment #0 and I see the desired behaviour (ie the PDF opens directly).

If you open the Firefox options and search for "PDF", what does it say in the table of filetypes (including PDF) next to the PDF entry? Changing that from "Always ask" to "Open in Firefox" may help resolve the issue.

Comment 3

[Andy Mercer]

I have it set to always ask. That is why it's popping up with those options in the video that I attached. Is the behavior that I'm seeing in the screencap not what you are seeing?

Comment 4

[:Gijs (out for now; he/him)]

(In reply to Andy Mercer from comment #3)

I have it set to always ask. That is why it's popping up with those options in the video that I attached. Is the behavior that I'm seeing in the screencap not what you are seeing?

Sure, I'm saying... don't set it to always ask? If you set it to "Open with Firefox", then you won't get the popup and the problem goes away...

Comment 5

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:bdahl, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 6

[Andy Mercer]

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

(In reply to Andy Mercer from comment #3)

I have it set to always ask. That is why it's popping up with those options in the video that I attached. Is the behavior that I'm seeing in the screencap not what you are seeing?

Sure, I'm saying... don't set it to always ask? If you set it to "Open with Firefox", then you won't get the popup and the problem goes away...

Sorry, I misread what you were saying as backwards. My apologies.

I switched it to "Open in Firefox", and it functions correctly. That means that the bug only happens when it's set to "Always Ask", and the user manually chooses to "Open in Firefox".

Comment 7

[Andy Mercer]

Attachment: AskEverytimeVsDefault.mp4

Comment 8

[Andy Mercer]

I've added a new screencap of the following:

A. PDFs are set to "Always Ask", and user selects "Open in Firefox". In this case, FF downloads the PDF and then opens.
B. PDFs are set to "Open in Firefox". In this case, FF opens correctly without appearing to download at all.

Comment 9

[:Gijs (out for now; he/him)]

(In reply to Andy Mercer from comment #6)

That means that the bug only happens when it's set to "Always Ask", and the user manually chooses to "Open in Firefox".

Right. That "Open in Firefox" option in the dialog is actually new. Before, if you had it set to "always ask" (or if the server sent content-disposition: attachment), opening in Firefox was not offered as an option (and if you picked it as a third-party app using the "Open with [dropdown]" entry, you could get into an infinite loop ).

PDF Handling: When user manually selects "Open in Firefox", Firefox downloads and then opens.

I don't think we can realistically fix that without completely rewriting a large portion of our codebase. As it is, the way things work is we make a request, the server passes us some response headers and starts sending us the file, and we need to do something while the dialog comes up... if we aren't sure the user wants us to show whatever the server is sending us inline (and/or if we are able to do so), we show the dialog in question, and download the file in the background. I don't think there is currently a mechanism to repurpose that data channel into something from which to read the pdf "directly" (though obviously from a technical perspective, the "download" happens either way - the PDF's bytes need to make it to pdfjs one way or another!).

Can you elaborate on why you need this fixed? What problem would be addressed - is it just about the value of the URL bar? Or about the data being on disk? Or about something else?

Comment 10

[Andy Mercer]

There are three reasons:

A. Internal Consistency: The behavior between one-time Open in Firefox and always Open in Firefox (from settings) should match.
B. Cross-Browser Consistency: The behavior between Firefox and Chromium-based browsers should match.
C: User Expectation: When a user selects "Open in Firefox" instead of "Download", they expect the PDF to not be downloaded.

I mean, again, when a user goes to the options menu and selects always Open in Firefox, what happens then is DIFFERENT, than if they say ask, and then when being asked, select Open in Firefox. Open in Firefox should always do the same thing, regardless of if it's being selected as a one time thing, or a default.

Comment 11

[Andy Mercer]

To add more context to reason C. At my company, Firefox is pretty well used. Roughly 20 users. I've had two people come to me independently over the past two weeks and ask (paraphrasing): Why our website is making them download PDFs now instead of just opening in Firefox.

With one of them, I asked her to go to options and change it to Open in Firefox, and her response was, that's what I've been clicking each time in the popup and it just downloads it. Why should I change it to default to the broken option?

Comment 12

[Andy Mercer]

Here is an idea. The differences in behavior boil down to:

A. New tab opens, or doesn't open.
B: The URL changes to the local file path on the computer, or stays as the website URL.

Could it just be faked? Instead of rewriting the entire code base? Like, display the source URL, rather than the downloaded file location.

Or, at the very least, the text for the popup option could be changed. Because it isn't just opening in Firefox. It's downloading and then opening in Firefox. If the behavior doesn't match what happens when the default is set (in Options) to Open in Firefox, then the text shouldn't match either.

Sorry for splitting into three comments.

Comment 13

[:Gijs (out for now; he/him)]

Making the option behave the same way in general is difficult, unfortunately.

(In reply to Andy Mercer from comment #12)

Could it just be faked? Instead of rewriting the entire code base? Like, display the source URL, rather than the downloaded file location.

Not really, because the rest of the address bar and Firefox code would need to do the "right" thing, too (e.g. bookmarks UI, page info, the identity/"lock" icon, etc.), and for some of them (esp. the identity/lock icon) the information may then not be available because there is no real http/https connection anymore.

Or, at the very least, the text for the popup option could be changed. Because it isn't just opening in Firefox. It's downloading and then opening in Firefox. If the behavior doesn't match what happens when the default is set (in Options) to Open in Firefox, then the text shouldn't match either.

But the "Open in [application]" text has always been labeled like this - the "download" part is implied ("Download and open..." and "Download and save...").

The "Open in Firefox" option used to be labeled "Preview in Firefox" in the options, and that was changed because it was felt this was a more accurate/obvious use of language. I agree that the symmetry is unfortunate, but I don't think it warrants adding "Download and..." to all the options in the dialog.

(In reply to Andy Mercer from comment #10)

B. Cross-Browser Consistency: The behavior between Firefox and Chromium-based browsers should match.

The download behaviour between these browsers is pretty different to begin with. But as far as I can tell, the behavior for PDFs served as downloads is similar, and Chrome offers no way to ask the user what they want to do with the PDF every time. When a website serves up a PDF with content-disposition: attachment then Chromium-based browsers (well, at least Google Chrome, which I tested - I guess any other skins can do what they like) will download it, and then offer users the option to open it, at which point it opens from the local disk. It does not "just" open that file in a tab directly. (example: https://www.seattlesymphony.org/~/media/files/notes/schubert-sonata-21-b-flat.pdf ).

(In reply to Andy Mercer from comment #11)

To add more context to reason C. At my company, Firefox is pretty well used. Roughly 20 users. I've had two people come to me independently over the past two weeks and ask (paraphrasing): Why our website is making them download PDFs now instead of just opening in Firefox.

With one of them, I asked her to go to options and change it to Open in Firefox, and her response was, that's what I've been clicking each time in the popup and it just downloads it. Why should I change it to default to the broken option?

So between this and comment #0 ("used to handle this situation"), it seems that for you and/or some of your users, the option got changed to "always ask". Do you know if the users deliberately changed this? I'm not aware of any changes on our side that were meant to have this effect. If anything, it sounds like the opposite of what both we and the users want. PDFs that are presented by the website without an explicit Content-Disposition header indicating download, should get opened immediately ("without download") in a tab in Firefox. This is the default in a new Firefox profile (and has been for a long time). So I'm confused how your users ended up in this situation. Do you have any idea how this happened?

Comment 14

[Andy Mercer]

Regarding how a setting may have changed:

I am not aware of users deliberately changing settings (and I didn't). I have had issues with updates in the past, though. Around FF 70 (I think), the screenshot tool stopped working after an update until I uninstalled and reinstalled. Beyond that, I don't know. I've switched both users over to always open in Firefox through options. I'm also going to test out and see if I can remove the Content-Disposition header.

Regarding the behavior:

From what you're saying, it sounds like the current behavior is what it's going to stay. For the record, I still thing that having two text strings that are identical but describe different behaviors is extremely confusing, but it is what it is. I appreciate your willingness to discuss it.

Comment 15

[Andy Mercer]

Incidentally, I just checked and on the reference link (https://www.functionaldevices.com/support/downloads/datasheet-generator/?SKU=RIBU1C), the response headers are:

Content-Disposition: inline; filename="RIBU1C.pdf"; filename*=utf-8''RIBU1C.pdf

It isn't using "attachment".

Comment 16

[:Gijs (out for now; he/him)]

(In reply to Andy Mercer from comment #14)

Regarding how a setting may have changed:

I am not aware of users deliberately changing settings (and I didn't). I have had issues with updates in the past, though. Around FF 70 (I think), the screenshot tool stopped working after an update until I uninstalled and reinstalled. Beyond that, I don't know. I've switched both users over to always open in Firefox through options.

Hm. Mystery... :-(

I'm also going to test out and see if I can remove the Content-Disposition header.

Yeah, if this is a website you control this sounds like it might make people on other browsers happy, too. There are also add-ons that can be used to overwrite problematic headers, if people want to always display directly in Firefox and that isn't currently possible because the website says "no really this is a download".

Regarding the behavior:

From what you're saying, it sounds like the current behavior is what it's going to stay.

Well, there are medium-term (more than a few weeks, less than 6 months) plans to make more changes to downloads, and then some of this may be cleared up further. But unfortunately there are a lot of different possibilities in the current setup, and making things easier / more obvious for some set of users is tricky without making it worse for other sets of users - we have to be careful and ensure different workflows are accommodated. We're working through this, but there's no finished plan just yet. Sorry!

For the record, I still thing that having two text strings that are identical but describe different behaviors is extremely confusing, but it is what it is.

I absolutely agree that there is a potential for confusion here, and it would be good to address that. It's the "how" that is tricky.

I appreciate your willingness to discuss it.

Likewise - thank you for helping make Firefox better!

Comment 17

[:Gijs (out for now; he/him)]

(In reply to Andy Mercer from comment #15)

Incidentally, I just checked and on the reference link (https://www.functionaldevices.com/support/downloads/datasheet-generator/?SKU=RIBU1C), the response headers are:

Content-Disposition: inline; filename="RIBU1C.pdf"; filename*=utf-8''RIBU1C.pdf

It isn't using "attachment".

Right; apologies for the confusion. The "what do you want to do with this file" dialog will only come up for "inline" documents if users have selected "ask me every time" for PDFs. For attachments, the dialog will always come up. In other browsers, there is no equivalent of this dialog (AFAIK) -- for inline documents, you can configure Chrome to either use its own viewer or the system default; for attachments, the browser will always save to disk and never open it in a tab.

From the perspective of your users, it sounds like we should just get rid of the "always ask" option - it causes confusion and isn't what they want. It sounds like they might also want to open "attachment" files in a tab without being asked.

Unfortunately, it turns out there are then other users that sometimes want to open things in Firefox, and sometimes to download and open them with their system viewer (cf. discussion in bug 1653807). Making things work for everyone is tricky - as I said in my previous comment, we're working on it. :-)

Comment 18

[Andy Mercer]

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

Right; apologies for the confusion. The "what do you want to do with this file" dialog will only come up for "inline" documents if users have selected "ask me every time" for PDFs. For attachments, the dialog will always come up. In other browsers, there is no equivalent of this dialog (AFAIK) -- for inline documents, you can configure Chrome to either use its own viewer or the system default; for attachments, the browser will always save to disk and never open it in a tab.

Gotcha, okay.

From the perspective of your users, it sounds like we should just get rid of the "always ask" option - it causes confusion and isn't what they want. It sounds like they might also want to open "attachment" files in a tab without being asked.

Unfortunately, it turns out there are then other users that sometimes want to open things in Firefox, and sometimes to download and open them with their system viewer (cf. discussion in bug 1653807). Making things work for everyone is tricky - as I said in my previous comment, we're working on it. :-)

And yeah, there are a lot of different opinions. I think we can close this ticket, and I'll just see what comes with the medium-term changes you said are planned. Again, thanks for the discussion.