Open Bug 1485915 Opened Last year Updated Last year
"Open File" obeys site-specified content types too aggressively
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0 Build ID: 20180820172315 Steps to reproduce: 1. Go to Patreon (eg. https://www.patreon.com/egscomics/) 2. Click to download an attachment (eg. https://www.patreon.com/file?h=665009&i=15254 ) 3. Choose "Save File" and let the download complete 4. Click the download in the downloads panel to open it Actual results: 1. The "You have chosen to open" dialog will list the file type as "unknown" and, on my system, the "Open with" dropdown lists my primary (but not alternative) mimeapps.list association for application/octet-stream. (Specifically, my ~/.local/share/mimeapps.list contains "application/octet-stream=wxHexEditor.desktop;gvim.desktop;leafpad.desktop;" and Firefox populates the dropdown with wxHexEditor but not the others.) 2. Clicking the file to open it once it's been downloaded causes it to open in wxHexEditor. (Likewise, when I rename a .zip download to .cbz in the Save dialog, I expect it to open in Comix, not File-Roller.) Expected results: Clicking a file in the downloads pane should have the same behaviour as choosing Open Containing Folder and then double-clicking it there. (On Linux, I believe this is also a Chrome parity issue, since, from what I remember, Chromium justs uses xdg-open as the handler for everything and lets the OS sort it out.) As-is, I'm wary of using Firefox's built-in Open File option because, when I see a file with a name like FooBar.pdf or Wallpaper.png, I don't expect it to open in wxHexEditor and, when I forget and click a file named Thing.cbz, it's very frustrating to see it come up in an archive manager with no toolbar button or menu option to "reopen in associated application" rather than the comic reader I expected, just because the server was configured to serve it with a Zip content type.
(In reply to Stephan Sokolow from comment #0) > Clicking a file in the downloads pane should have the same behaviour as > choosing Open Containing Folder and then double-clicking it there. I agree. In most cases, we choose a file extension that matches the content type already, but if the user changes the file extension manually when saving the file, we should use the new file extension for finding the application with which to open it. With the current code complexity and multiple download paths, this may not be trivial to implement in all cases, and we have to keep into account Application Reputation checks and executableness, but is something we should investigate.
Status: UNCONFIRMED → NEW
Component: Untriaged → Downloads Panel
Ever confirmed: true
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.