1817752 - [win] Open with has empty dropdown option displayed if the zip download type is set to Always ask and Windows doesn't know about application/zip

Status: NEW

(Firefox :: File Handling, defect, P3)

Description

[Alexandru Trif, Desktop Test Engineering [:atrif]]

Attachment: image

Found in

• 111.0b3

Affected versions

• 112.0a1 (2023–02-19)
• 111.0b2
• 110.0
• 102.8.0esr (affected by )

Tested platforms

• Affected platforms: Windows 10x64, Windows 7x64
• Unaffected platforms: Ubuntu 20.04, macOS 12

Steps to reproduce

1. Download a random file like http://ipv4.download.thinkbroadband.com/5MB.zip.
2. Open the downloads drop-down and select the Always open similar files by r-clicking the downloaded item.
3. Open about:prefrences and scroll down to the downloads sections.
4. Set the Always ask action for the zip content type.
5. Download again http://ipv4.download.thinkbroadband.com/5MB.zip and observe the window.

Expected result

• The Open with the dropdown menu is autocompleted with Use Window explorer (that is what is happening on macOS 12 and Ubuntu 22)

Actual result

• Empty drop-down menu.

Regression range

• There are two bugs that changed this behavior:

1. Bug 1746052 removed the Open with dropdown and placed only a Browse button.
2. Bug 1689816 added the Open with dropdown back but it’s empty.

I will set bug 1746052 as the initial regressor. Feel free to change it if you feel otherwise.

Additional notes

• Attached a screenshot.

Comment 1

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

:enndeakin, since you are the author of the regressor, bug 1746052, could you take a look?

For more information, please visit auto_nag documentation.

Comment 2

[Neil Deakin]

I can't reproduce this.

Comment 3

[Walter K.]

Attachment: Empty Open with list when saving .png

I saw the same behavior today when saving a .png attachment from Gmail.
I have Ask whether to open or save files selected in the settings as well.

FF Dev Edition 111.0b4

Comment 4

[Marco Bonardo [:mak]]

When validating the name here
https://searchfox.org/mozilla-central/rev/3c3ad00ab7f587e2c75e8cebb89badc4e946b10e/uriloader/exthandler/nsExternalHelperAppService.cpp#3350-3363
we end up here
https://searchfox.org/mozilla-central/rev/3c3ad00ab7f587e2c75e8cebb89badc4e946b10e/uriloader/exthandler/win/nsOSHelperAppService.cpp#475-478
and we create a new nsMIMEInfoWin for flatType application/zip because the registry doesn't know about it.

Then we proceed to FillMIMEInfoForMimeTypeFromExtras
https://searchfox.org/mozilla-central/rev/3c3ad00ab7f587e2c75e8cebb89badc4e946b10e/uriloader/exthandler/nsExternalHelperAppService.cpp#3091,3101,3111,3119
and this adds the zip extension to the mimeInfo because of extraMimeEntries.
Zip becomes the primary extension, being the only extension.

So when we reach
https://searchfox.org/mozilla-central/rev/3c3ad00ab7f587e2c75e8cebb89badc4e946b10e/uriloader/exthandler/nsExternalHelperAppService.cpp#3364,3368-3369
we have a primary extension and we don't ask again to GetFromTypeAndExtension with the extension.

Short, we built a mime info from scratch, and assigned it a mime type a description, and an extension.

Off topic:
I also noticed for the icon channel we enter GetFromTypeAndExtension with aFileExt starting with a dot, while I'd expect this method to take a dot-less extension. Maybe it could be worth spreading around some MOZ_ASSERT to those methods expecting a dot-less extension?
https://searchfox.org/mozilla-central/rev/3c3ad00ab7f587e2c75e8cebb89badc4e946b10e/uriloader/exthandler/nsExternalHelperAppService.cpp#2843 (here we compare zip to .zip)

Comment 5

[Marco Bonardo [:mak]]

Gijs, when you have time, could you please check if this makes sense or should I investigate deeper? I'm assuming we use the mimeinfo built here to fetch possible applications to handle it (though I didn't verify that), and it's also compatible with the reg-range.

Comment 6

[Marco Bonardo [:mak]]

Confirming as a valid backlog bug.