Open Bug 1738918 Opened 3 years ago Updated 9 months ago

"Always open similar files" is not available for files sent with `application/octet-stream` mimetypes

Categories

(Firefox :: Downloads Panel, defect, P3)

Desktop
All
defect

Tracking

()

Tracking Status
firefox96 --- disabled
firefox97 --- disabled
firefox98 --- wontfix
firefox99 --- affected

People

(Reporter: Gijs, Unassigned)

References

(Depends on 1 open bug, Blocks 2 open bugs)

Details

(Whiteboard: [fidefe-mr11-downloads])

STR:

  1. On a system without a ruby interpreter or something associated with rb files, go to https://filesamples.com/formats/rb (if you do use ruby, pick a language your machine hasn't heard of at https://filesamples.com/categories/code , or an image format it doesn't know at the images page )
  2. download one of the sample files
  3. right click the completed download in the download panel

ER:
can ensure the filetype shows up in prefs

AR:
cannot ensure the filetype shows up in prefs

This is unfortunate because in prefs, I could say that I want to open this image/code file with photoshop / my default code editor / whatever, even if that's not the OS default. As it is this is not possible.

Severity: -- → S3
Priority: -- → P3

Currently, we [make the decision to hide the "Always open similar files" item here. I suspect that shouldNotRememberChoice is evaluating true here since we mimic the decision to the UCT window makes when hiding the "remember choice" checkbox.

For this section of code:

let shouldNotRememberChoice =
  download.contentType === "application/octet-stream" ||
  download.contentType === "application/x-msdownload" ||
  (download.contentType === "text/plain" &&
    gReputationService.isBinary(download.target.path));

It's possible the ReputationService.isBinary(download.target.path) condition here could be a security hole if removed?

Flags: needinfo?(gijskruitbosch+bugs)

OK, turns out this is related to the mimetype being useless - the filesamples.com site sends application/octet-stream for these files, even though better mimetypes are available (text/x-ruby is probably best in this case).

That is kind of unfortunate - we should be able to use the file extension, if provided, to determine a better mimetype and store a decision for that mimetype (and then rely on that better mimetype if possible). However, this involves work and is probably interrelated with bug 1659008.

Flags: needinfo?(gijskruitbosch+bugs)
See Also: → 1659008
Summary: "Always open similar files" is not available for files that have no system default handler → "Always open similar files" is not available for files sent with `application/octet-stream` mimetypes
See Also: → 1740840

Assigning myself to this bug since it seems to be fixable by Bug 1740840

Assignee: nobody → kpatenio
Status: NEW → ASSIGNED

As of December 2, 2021, the patch for Bug 1740840 should have already landed. Testing with .rb files, I can confirm that the "Always Open Similar Files" option appears on MacOS Big Sur and Ubuntu 20.04.3 LTS using the latest version of Nightly. However, it still doesn't seem to work on Windows 10.

(In reply to kpatenio from comment #4)

As of December 2, 2021, the patch for Bug 1740840 should have already landed. Testing with .rb files, I can confirm that the "Always Open Similar Files" option appears on MacOS Big Sur and Ubuntu 20.04.3 LTS using the latest version of Nightly. However, it still doesn't seem to work on Windows 10.

I suspect the answer might be that given https://searchfox.org/mozilla-central/rev/33641307ec33033f5129826d8d6eda19feb8a01f/uriloader/exthandler/win/nsOSHelperAppService.cpp#437 and the fact that the Windows registry will have no idea about the mimetype of rb files, we keep the application/octet-stream mimetype and are unable to determine a better mimetype, so we still don't display the "always open similar files" option. Does that seem right?

I'm not sure there's much we can do about that unless we come up with a better way of associating actions stored in handlerservice.js with extensions rather than mimetypes...

Flags: needinfo?(kpatenio)

I can definitely see that happening. Too bad it's not as straightforward of a fix for Windows. :/
Currently not sure of other ways to work around this. I do think though it'd be worth looking further into.

Flags: needinfo?(kpatenio)

Right now, this is partially resolved (currently not working for Windows).

Several changes are required, which could potentially conflict with other patches. For now, I think it would be best to wait for bug 1659008, which deals with a very similar issue as this.

Depends on: 1659008
Blocks: 1740841
No longer blocks: 1733587
Blocks: 1744297
See Also: 1659008
Assignee: kpatenio → nobody
Status: ASSIGNED → NEW

Firefox 98 shipping soon, updating flags.

See Also: → 1828441
You need to log in before you can comment on or make changes to this bug.