1742693 - Handlers.json opens certain file types with no user interaction despite preferences indicating the filetype is set to "always ask"

Status: NEW

(Firefox :: File Handling, defect, P3)

Description

[Mike Kaply [:mkaply]]

Attachment: handlers.json

We had a customer give us a handlers.json (attached) that has this in mimeTypes:

		"binary/octet-stream": {
			"action": 4,
			"extensions": ["dmg", "mp4", "iso", "pdf"]
		},

as a result, when they download ISO files, they get opened by the operating system, but there is no entry in preferences->Applications that allows them to change binary/octet-stream

They don't know how they got in this state.

Some example ISOs that did this are:

https://ubuntu.com/download/desktop
http://centos.westmancom.com/8-stream/isos/x86_64/
https://www.linuxmint.com/edition.php?id=288
https://archive.org/details/microsoft-works-9

Comment 1

[:Gijs (he/him)]

I can't reproduce comment 0 - if I use this file, the entry for binary/octet-stream shows up as "DMG file" in the prefs, and I can change that to "save to disk" and that works (gets written to the handlers.json file as expected).

Can you clarify any steps I might be missing?

I think it's confusing this mimetype ends up in this file at all, but I think that's covered by bug 1659008.

Comment 2

[Mike Kaply [:mkaply]]

Sure.

On Windows at least, I do see that DMG says Always Ask but when I download a DMG (or ISO) it is sent to the operating system immediately and opened.

I am not presented with a helper dialog at all.

So the "Always Ask" is not being honored.

Comment 3

[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 4

[:Gijs (he/him)]

(In reply to Mike Kaply [:mkaply] from comment #2)

Sure.

On Windows at least, I do see that DMG says Always Ask

On release or on nightly? And are the folks who reported this on release or on nightly?

Comment 5

[:Gijs (he/him)]

I guess more broadly, you filed this with the summary "and no way to change", which seems to imply there's no entry in the prefs that allows changing this, which isn't the case.

If the contents of that entry are lying, that's bad, but we should really try to narrow down where this is happening (and if it's just for octet-stream or also other stuff) before we'll stand a chance of fixing it.

Comment 6

[Mike Kaply [:mkaply]]

Attachment: DMG entry in nightly

The info in preferences is definitely incorrect. Image attached.

So I think what's confusing here is that there are two issues (one being addressed by the other bug).

The original problem that the user reported was "ISOs are opening automatically and I can't figure out how to change that"

So problem 1:

ISO is not in the list (that's the octet/stream problem).

Problem 2:

ISO opening automatically even though DMG says Always Ask in the UI.

So should I morph this bug to cover problem 2 since we have a bug for problem 1?

Comment 7

[:Gijs (he/him)]

(In reply to Mike Kaply [:mkaply] from comment #6)

Created attachment 9254317 [details]
DMG entry in nightly

The info in preferences is definitely incorrect. Image attached.

So I think what's confusing here is that there are two issues (one being addressed by the other bug).

The original problem that the user reported was "ISOs are opening automatically and I can't figure out how to change that"

So problem 1:

ISO is not in the list (that's the octet/stream problem).

Problem 2:

ISO opening automatically even though DMG says Always Ask in the UI.

So should I morph this bug to cover problem 2 since we have a bug for problem 1?

I think it's both the other bug - in that bug the entry is blank, here it is a lie (says always ask instead of the right thing). I expect in both cases the reason is that it can't find an OS default application for the extension + mimetype combination. Does that sound reasonable?

I'm still curious whether this is nightly-specific or happens on release as well as nightly, or release only.

Comment 8

[Mike Kaply [:mkaply]]

Attachment: Comparison nightly on right release on left

Same behavior with release and nightly.

DMG says Always Ask but ISOs open immediately.

Side note, release has three repeated entries that aren't in release...

Comment 9

[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 10

[:Gijs (he/him)]

(In reply to Mike Kaply [:mkaply] from comment #8)

Created attachment 9254420 [details]
Comparison nightly on right release on left

Same behavior with release and nightly.

DMG says Always Ask but ISOs open immediately.

Side note, release has three repeated entries that aren't in release...

This last sentence doesn't really make sense - I'm assuming you're referring to the 3 entries for various zip file mimetypes in the nightly screenshot (right) vs one in the release one (left) - they are duplicated because we store information on a per-mimetype basis, and there are 3 different mimetypes for zips in that handlers.json . I don't know off-hand why release would take the same information and display it differently tbh.

Linking this to bug 1740841 which seems to have a similar issue as well.

Comment 11

[jayjayjazz]

Maybe, I could add some additional information, which is hopefully a bit helpful:

1. Using a Linux machine with KDE
2. Fresh installation of Firefox 98.x (and of course fresh profile)
3. Download an ISO file
4. File is directly opened in Ark (archive manager in KDE)

• Ark is set as default application for *.ISO files in KDE
• Firefox does not have a handler in the handlers.json:

{"defaultHandlersVersion":{},"mimeTypes":{"application/pdf":{"action":3,"extensions":["pdf"]},"image/webp":{"action":3,"extensions":["webp"]},"image/avif":{"action":3,"extensions":["avif"]}},"schemes":{"mailto":{"stubEntry":true,"handlers":[null,{"name":"Gmail","uriTemplate":"https://mail.google.com/mail/?extsrc=mailto&url=%s"}]}},"isDownloadsImprovementsAlreadyMigrated":true,"isSVGXMLAlreadyMigrated":true}

As I haven't found any setting in Firefox preventing that a downloaded file is opened always without asking, I reverted to the old behavior via:

browser.download.improvements_to_download_panel

Comment 12

[:Gijs (he/him)]

(In reply to jayjayjazz from comment #11)

Maybe, I could add some additional information, which is hopefully a bit helpful:

1. Using a Linux machine with KDE
2. Fresh installation of Firefox 98.x (and of course fresh profile)
3. Download an ISO file
4. File is directly opened in Ark (archive manager in KDE)

• Ark is set as default application for *.ISO files in KDE
• Firefox does not have a handler in the handlers.json:

{"defaultHandlersVersion":{},"mimeTypes":{"application/pdf":{"action":3,"extensions":["pdf"]},"image/webp":{"action":3,"extensions":["webp"]},"image/avif":{"action":3,"extensions":["avif"]}},"schemes":{"mailto":{"stubEntry":true,"handlers":[null,{"name":"Gmail","uriTemplate":"https://mail.google.com/mail/?extsrc=mailto&url=%s"}]}},"isDownloadsImprovementsAlreadyMigrated":true,"isSVGXMLAlreadyMigrated":true}

As I haven't found any setting in Firefox preventing that a downloaded file is opened always without asking, I reverted to the old behavior via:

browser.download.improvements_to_download_panel

This is likely a separate issue, as there is no mention of any relevant mimetype in there at all (unlike comment 0 and the original report, where that is the case, and which predated the changes to the downloads which you just preffed off and which you say fix the issue for you!). Can you file a separate bug, and in addition to these details, also confirm you're testing with an official mozilla.org copy of Firefox (ie not a distro-provided one), clarify if you're using a snap or flatpak build of Firefox, and provide a link to an iso file with which you're seeing this problem? Thank you!

Comment 13

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

Clear a needinfo that is pending on an inactive user.

Inactive users most likely will not respond; if the missing information is essential and cannot be collected another way, the bug maybe should be closed as INCOMPLETE.

For more information, please visit auto_nag documentation.

Comment 14

[jayjayjazz]

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

(In reply to jayjayjazz from comment #11)

Maybe, I could add some additional information, which is hopefully a bit helpful:

1. Using a Linux machine with KDE
2. Fresh installation of Firefox 98.x (and of course fresh profile)
3. Download an ISO file
4. File is directly opened in Ark (archive manager in KDE)

• Ark is set as default application for *.ISO files in KDE
• Firefox does not have a handler in the handlers.json:

{"defaultHandlersVersion":{},"mimeTypes":{"application/pdf":{"action":3,"extensions":["pdf"]},"image/webp":{"action":3,"extensions":["webp"]},"image/avif":{"action":3,"extensions":["avif"]}},"schemes":{"mailto":{"stubEntry":true,"handlers":[null,{"name":"Gmail","uriTemplate":"https://mail.google.com/mail/?extsrc=mailto&url=%s"}]}},"isDownloadsImprovementsAlreadyMigrated":true,"isSVGXMLAlreadyMigrated":true}

As I haven't found any setting in Firefox preventing that a downloaded file is opened always without asking, I reverted to the old behavior via:

browser.download.improvements_to_download_panel

This is likely a separate issue, as there is no mention of any relevant mimetype in there at all (unlike comment 0 and the original report, where that is the case, and which predated the changes to the downloads which you just preffed off and which you say fix the issue for you!). Can you file a separate bug, and in addition to these details, also confirm you're testing with an official mozilla.org copy of Firefox (ie not a distro-provided one), clarify if you're using a snap or flatpak build of Firefox, and provide a link to an iso file with which you're seeing this problem? Thank you!

I am really sorry for the long delay in my answer.
You were correct. It was an issue in "kmozillahelper" in openSUSE TW. See this bug:
https://bugzilla.opensuse.org/show_bug.cgi?id=1197319