1762869 - Download action setting not respected

Status: RESOLVED INCOMPLETE

(Firefox :: File Handling, defect)

Description

[marco.morandini]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:98.0) Gecko/20100101 Firefox/98.0

Steps to reproduce:

This is likely a dup of #1760536 but I'm on Linux and it definitely does not work for me. Don't know if opening a new bug, instead of trying to reopen that, is the right thing to do. If not, please bear with me.

I've set "Always ask" for "Portable Document Format (PDF) (application/binary)", "Portable Document Format (PDF) ("application/pdf")" and "Portable Document Format (PDF) (file/pdf)". There are no other pdf types there.

I have the internal pdf viewer disabled, and resort to okular to view pdf files.

Actual results:

If in "Downloads" I set "Save files to" (an existing directory) the file get saved there, without asking what to do with it.
If, instead, I choose "Always ask you where to save files" I get a windows asking me where to save the file. After the file has been saved I can open if following the new workflow described in the release notes of Version 98.

This happens with all pdf files for me, e.g. with
https://figshare.com/ndownloader/files/27767343

Expected results:

I should get a prompt asking me what to do with the file, either save or open it. It's clear to me that, in order to view it, it needs to be downloaded and stored somewhere. However, the previous behavior was better, at least for me: whenever I wanted to view the file, and then drop it into oblivion, I could choose "open with"; the file would have been saved into /tmp, I I had the guarantee that it would have been automatically deleted sooner or later. Had I chose "save" then I could have put it in the right place (as with "Always ask you where to save files"). However, now the file first get saved, and then I need additional mouse clicks.
If I want to view it and then drop it I need to open it, and then delete the file, unless I choose "/tmp" as dowload folder. But this requires more mouse click (to open it, and the to delete). If instead I choose "/tmp" as the default download folder then I need more mouse clicks whenever I want to keep the file, or save it without first looking at it.

I'm on Linux, Firefox 98.0.2 , OpenSUsE tumbleweed.

Comment 1

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

The Bugbug bot thinks this bug should belong to the 'Firefox::File Handling' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[:Gijs (he/him)]

Can you share the handlers.json file from your profile?

Does it work with https://www.americanexpress.com/content/dam/amex/us/staticassets/pdf/GCO/Test_PDF.pdf ?

For reference, the server for the link in comment 0 provides no content type at all (ie I'm not sure that we'd be able to treat it as a PDF - we just know it's not HTML and download it - either way it'd be good to confirm if this explains what is happening or not). You wrote this happens for "all pdf files" - I wonder if you download all/most of them from this server, or others that provide no content-type.

Comment 3

[marco.morandini]

Attachment: handlers.json

handlers.json attached.

Opening https://www.americanexpress.com/content/dam/amex/us/staticassets/pdf/GCO/Test_P
DF.pdf with "Always ask you where to save files" selected and "Always ask" for the pdfs brings up the "Enter name or file to save to..." windows

Comment 4

[marco.morandini]

One more comment: right now it works. I think that this is because when it was not working the available pdf types in the customization menu were only three,

• Portable Document Format (PDF) (application/binary)
• Portable Document Format (PDF) ("application/pdf")
• Portable Document Format (PDF) (file/pdf)

while now I have a fourth entry:

• Portable Document Format (PDF) (application/pdf)

without the "" enclosing application/pdf.
Now, I don't know why this happened (screwed up mimetypes in my system?), nor if/what system update changed this.

However, whenever this happens it's really confusing, and if the reason is this there should be a way to add a file type. This is the only reason fr which I'm not closing this bug.

At any rate, apologize for likely wasting your time, and thank you for any info/suggestion you may have!

Comment 5

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

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

For more information, please visit auto_nag documentation.

Comment 6

[:Gijs (he/him)]

Ooof, sorry for the long silence here.

So, a few things of note:

1. Firefox associates default applications using mime types. Unfortunately those aren't very user-friendly, so adding UI to add arbitrary mimetype/extensions to about:preferences doesn't feel like something that would really help a lot of people. If you know what mimetypes are and you feel like that kind of thing would help you, it's probably also possible for you to manually add entries into handlers.json. We might move to having actions coupled to file extensions instead of mimetypes, and then we'd want to revisit not having the ability to add items to the list.
2. PDF didn't show up in the list if you had pdf.js disabled (which you noted in comment 0). This got fixed in bug 1759984, in Firefox 101 which is currently in beta. It should show up reliably on those versions (though it also sounds like it got added back for you already, perhaps because you used the context menu on a PDF with the "right" mimetype...)
3. I... don't know why your handlers.json / handlers list has "strange" mimetypes like "application/pdf" in quotes etc. If you've used Firefox for a long time and this user profile isn't too new, it might be related to something like bug 306471 or its friends which were fixed a few years ago - ie a server once sent you a PDF with bogus mimetypes and, if you changed an action, that mimetype got permanently stored, and is still in the database in your profile.

At this point, I don't think we're going to find out why it was broken for you before (when it does work now), so I think I'll close this out. Thank you for the report - not a waste of time, it's always good to make sure we fully understand what is going on, inasmuch as that is ever possible...