1738111 - Can't properly configure filetype added to preferences via "Always Open Similar Files"

Status: VERIFIED FIXED

(Firefox :: Downloads Panel, defect, P1)

Description

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

It is not possible anymore to control Action of Filename Extension Types, which are not present in Mozilla Firefox by default.

".torrent" and other Content Types are not added to Applications section after first download, making it impossible to set "Open" preference to always open it in BitTorrent client or other external software, instead of being downloaded and opening it in manually, like it's now.

STR:

1. Open https://ubuntu.com/download/alternative-downloads
2. Download from there torrent for Ubuntu 21.10 Desktop (64-bit)
3. Open Applications section in General tab in Settings ( about:preferences#general )
4. Notice that Content Type for ".torrent" was not added there

The issue occurs for every other Filename Extension Type which is not currently present there by default.

Comment 1

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

[Tracking Requested - why for this release]: Regression from bug #1732347

Comment 2

[Micah [:mtigley] (she/her)]

Attachment: AlwaysOpenSimilarFilesMenuItem.png

You can configure new content types by using the "Always Open Similar Files" context menu item on the download in the panel. If it isn't already added, clicking on this menu item will save it to the "Content type" table with its action set to be handled externally. From there, you can configure the preferred action for that content type. The documentation in the release notes touched on this menu item in point 6, but doesn't mention that it also stores the new content type and can be configured from about:preferences.

Comment 3

[Alice0775 White]

I think this is ux-discovery issue.
And If the download icon is hidden by customize toolbar, no longer discover... :(

Comment 4

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

(In reply to Micah [:mtigley] (she/her) from comment #2)

Created attachment 9248110 [details]
AlwaysOpenSimilarFilesMenuItem.png

You can configure new content types by using the "Always Open Similar Files" context menu item on the download in the panel. If it isn't already added, clicking on this menu item will save it to the "Content type" table with its action set to be handled externally. From there, you can configure the preferred action for that content type. The documentation in the release notes touched on this menu item in point 6, but doesn't mention that it also stores the new content type and can be configured from about:preferences.

Unfortunately by this method the file is downloaded to the set download folder and later opened, instead of downloaded to TEMP folder and later opened. So users now have to clean these leftovers by themselves.
What is more, even with checked "Always Open Similar Files" in Downloads panel, Actions of Content Types do not show "Open", only: "Always ask", "Save File" and "Use other..." are present.

Comment 5

[:Gijs (he/him)]

This isn't shipping with 95 and doesn't need to be tracked for it.

(In reply to Alice0775 White from comment #3)

I think this is ux-discovery issue.

What is "this" here?

And If the download icon is hidden by customize toolbar, no longer discover... :(

Please file a separate ticket for this.

(In reply to Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.) from comment #4)

(In reply to Micah [:mtigley] (she/her) from comment #2)

Created attachment 9248110 [details]
AlwaysOpenSimilarFilesMenuItem.png

You can configure new content types by using the "Always Open Similar Files" context menu item on the download in the panel. If it isn't already added, clicking on this menu item will save it to the "Content type" table with its action set to be handled externally. From there, you can configure the preferred action for that content type. The documentation in the release notes touched on this menu item in point 6, but doesn't mention that it also stores the new content type and can be configured from about:preferences.

Unfortunately by this method the file is downloaded to the set download folder and later opened, instead of downloaded to TEMP folder and later opened. So users now have to clean these leftovers by themselves.

This is expected, as explained in the document. It is needed because otherwise there are scenarios where data loss occurs (the file gets deleted out of temp and the user has no opportunity to save a copy). It's also worth noting that this has always been the case on macOS, the Temp behaviour is Linux/Windows-specific.

What is more, even with checked "Always Open Similar Files" in Downloads panel, Actions of Content Types do not show "Open", only: "Always ask", "Save File" and "Use other..." are present.

Can you elaborate on what you mean?

Comment 6

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

Attachment: bug #1738111.png

Comment 7

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

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

(In reply to Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.) from comment #4)

Unfortunately by this method the file is downloaded to the set download folder and later opened, instead of downloaded to TEMP folder and later opened. So users now have to clean these leftovers by themselves.

This is expected, as explained in the document. It is needed because otherwise there are scenarios where data loss occurs (the file gets deleted out of temp and the user has no opportunity to save a copy). It's also worth noting that this has always been the case on macOS, the Temp behaviour is Linux/Windows-specific.

I am very sorry, but I do not logically understand where is the data loss issue there, because:

• if users want to only open and look temporarily or load files in external software, they will choose "Open" option
• if users want to save files permanently, they are choosing "Save" option
  so the ability to save files was always present for users or I am missing something? Can you elaborate on what you mean?

As for now, in my eyes, Mozilla is forcing all users into second category and forbid proper usage of "Open" feature. I do not know if it is because the competition has already identical feature and Mozilla want it in Firefox too or it is other case.

About macOS case, I'm hoping that Mozilla Firefox will not be tuned only to be compatible with macOS standards.

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

(In reply to Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.) from comment #4)

What is more, even with checked "Always Open Similar Files" in Downloads panel, Actions of Content Types do not show "Open", only: "Always ask", "Save File" and "Use other..." are present.

Can you elaborate on what you mean?

I meant that when users check "Always Open Similar Files" option in Downloads panel after they downloaded the non default file that is not present in Mozilla Firefox, it will be added with only: "Always ask", "Save File", "Use other..." options, and "Open" option will not be present. This prevent quickly and easily access to these settings, as when users want to change it again, they will have to redownload the non default file that is not present in Mozilla Firefox and change the setting in Downloads panel. This is worth to add that it is also accessibility issue. Please see the attachment.

Comment 8

[:Gijs (he/him)]

(In reply to Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.) from comment #4)

Unfortunately by this method the file is downloaded to the set download folder and later opened, instead of downloaded to TEMP folder and later opened. So users now have to clean these leftovers by themselves.

This is now tracked in bug 1738574, let's keep this bug focused on the issue you reported.

(In reply to Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.) from comment #7)

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

Can you elaborate on what you mean?

I meant that when users check "Always Open Similar Files" option in Downloads panel after they downloaded the non default file that is not present in Mozilla Firefox, it will be added with only: "Always ask", "Save File", "Use other..." options, and "Open" option will not be present. This prevent quickly and easily access to these settings, as when users want to change it again, they will have to redownload the non default file that is not present in Mozilla Firefox and change the setting in Downloads panel. This is worth to add that it is also accessibility issue. Please see the attachment.

Huh, this is confusing. Thanks for the screenshot. I can't easily reproduce. I don't have a torrent client installed, so the option isn't available for torrents for me (I'll file a separate bug for that). On Windows, when I download a txt file and then select the "Always Open Similar Files" option, the entry in prefs has "Use Notepad (default)" as the selected option, as expected.

Does this happen for all filetypes with which you try? Are there errors in the browser console when you either click the menuoption or open the preferences?

(also, just to confirm, despite the suggestion to download a Linux iso in comment 0, you're seeing this issue on Windows 7 per the platform field, is that right? If you have access to Windows 10, is the behaviour the same there?)

Comment 9

[:Gijs (he/him)]

Mass moving affected flag for download improvements issues found on Nightly to 96 (nightly from later today / tomorrow), as the download improvements pref will be disabled for 95 beta.

Comment 10

[:Gijs (he/him)]

In bug 1738706, it was noted that some of the weirdness here might be a regression from bug 1586355, which might be a clue as to what's going wrong here?

Comment 11

[Molly Howell (she/her) (no longer active)]

I don't think this is a new regression at all. I have two pieces of evidence for that assertion:

1. I can reproduce the bug in a 2020-11-03 Nightly (i.e., one year ago, which is as far back as mozregression would take me).
2. As best as I can tell, the code that's directly involved in making this bug happen was last touched well before our recent work on downloads.

Here's what looks to be happening as far as I can tell:

1. The initial download of a .torrent file triggers creation of an entry in our handlers database. This entry stores the file's MIME type (application/x-bittorrent) and links it to the file extension and the selected action for the type. So far, so good.
2. When the handlers list in about:preferences is constructed any time after that, it asks the handler service to iterate through all the handlers we have stored, so it can try to figure out how to represent them in the list. But, the handler service only attempts to look up the information we need (most relevantly, description strings for the type itself and for the handler app) based only on the stored MIME type.
3. Now we go to present the OS with that MIME type and ask it to look up a description and a handler app based on that. But, we're aware that that isn't actually possible on Windows, because it stores associations based on the file extension. So first we attempt to look up the MIME type in a registry key that maps MIME types to file extensions. But, since MIME types are not the primary way of handling file associations on Windows, this list isn't populated for every type and can't be fully relied upon. Therefore, for some types (including .torrent), we fail to find an entry that could tell us what the extension is, and so we can never find any registered handler app, whether there is one or not.
4. The handler service has now told that preferences page code that no handler app exists for .torrent, so it skips adding the item for "Open in [handler app]" to that type's menu.

The solution that all this suggests for me then would come in at step 2, where we could look up the file extension that we have stored (if there is one) and pass through to the OS alongside the MIME type. That heads off this bug by allowing the OS to find the handler app by whatever means it prefers, so that we can display information about it to the user in preferences.

Comment 12

[Molly Howell (she/her) (no longer active)]

Attachment: Bug 1738111 - Look up handler apps by file extension if one exists when enumerating handlers. r=gijs,mtigley

We're getting false negatives when checking for handler apps (at least on
Windows) because we're not bringing file extensions in that process even when
we know at least one we could use, we're only looking up associations based on
MIME types. That isn't reliable on Windows, so this patch adds the first
extension that we have stored in the handlers database to the search
parameters, which makes us more likely to find a handler if one is registered.

Comment 13

[Molly Howell (she/her) (no longer active)]

(giving this 3 points even though the patch is tiny because of how long the investigation took me, and because writing the test is also taking me a bit)

Comment 14

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/f7a9e5c1f8e2
Look up handler apps by file extension if one exists when enumerating handlers. r=Gijs,mtigley

Comment 15

[Marian-Vasile Laza]

https://hg.mozilla.org/mozilla-central/rev/f7a9e5c1f8e2

Comment 16

[Adrian Florinescu [:aflorinescu]]

I would assume that we also need a fix for the always open availlability -> bug 1738918, bug 1740840 ?

Comment 17

[Molly Howell (she/her) (no longer active)]

At least bug 1740934 and bug 1740840 are indeed blockers. Bug 1738918 I'm less sure about, it might need some discussion.

Comment 18

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

I'm confirming that the bug is fixed, starting in Mozilla Firefox Nightly 96.0a1 (2021-11-11), so I'm marking this bug as VERIFIED.
Thank you very much! \o/

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

(In reply to Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.) from comment #4)

Unfortunately by this method the file is downloaded to the set download folder and later opened, instead of downloaded to TEMP folder and later opened. So users now have to clean these leftovers by themselves.

This is now tracked in bug 1738574, let's keep this bug focused on the issue you reported.

Unfortunately bug #1738574 is now marked as WONTFIX and too bad that there won't be any option to change that behavior.

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

(In reply to Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.) from comment #7)

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

Can you elaborate on what you mean?

I meant that when users check "Always Open Similar Files" option in Downloads panel after they downloaded the non default file that is not present in Mozilla Firefox, it will be added with only: "Always ask", "Save File", "Use other..." options, and "Open" option will not be present. This prevent quickly and easily access to these settings, as when users want to change it again, they will have to redownload the non default file that is not present in Mozilla Firefox and change the setting in Downloads panel. This is worth to add that it is also accessibility issue. Please see the attachment.

Huh, this is confusing. Thanks for the screenshot. I can't easily reproduce. I don't have a torrent client installed, so the option isn't available for torrents for me (I'll file a separate bug for that). On Windows, when I download a txt file and then select the "Always Open Similar Files" option, the entry in prefs has "Use Notepad (default)" as the selected option, as expected.

Does this happen for all filetypes with which you try? Are there errors in the browser console when you either click the menuoption or open the preferences?

(also, just to confirm, despite the suggestion to download a Linux iso in comment 0, you're seeing this issue on Windows 7 per the platform field, is that right? If you have access to Windows 10, is the behaviour the same there?)

I will abstain to test it on older builds, as the main issue that I was having it now fixed in latest builds, but thank you very much for your interest in this bug. I appreciate it very much.