1597985 - Windows mime info gathering from the OS should prioritize file extensions over mimetypes when looking up handler information

Status: RESOLVED FIXED

(Firefox :: File Handling, defect, P1)

Description

[:Gijs (he/him)]

Description based on a discussion with Boris elsewhere (thank you!):

In particular, if we are given a type and an extension, and that extension is a valid extension for that type, and Windows does helper app lookup by extension, then we should be doing that lookup based on that extension.

What nsOSHelperAppService::GetMIMEInfoFromOS does right now is:

1. Get the default extension for the given type.
2. Look up the handler for that default extension.
3. If we found something, and the given extension is valid for the given type, add it to the MIME info.
4. If we found nothing for the default extension, look up info for the given extension.

or so (there are some more complications). It seems like the logic should be more like:

1. Look up the type for the given extension.
2. If this matches the given type, look up handlers by the given extension, since that's the extension we will end up using. We can use the existing nsOSHelperAppService::typeFromExtEquals thing on Windows for this, I bet.
3. Otherwise look up the default extension for the type and look up based on that [Gijs: note, and set the default extension as the extension for the mime info object. This is useful e.g. when we've determined the extension from the URL, and it's actually related to e.g. the server-side programming language (.exe, .cgi, etc.). ]
4. If none of that found anything useful, continue to look up by the given extension, I guess, as now? I'm not sure what exactly should happen here if the given extension does not match the given MIME type in any sort of useful way and there is no handler for the default exension for the given MIME type.

I have a patch that switches us to the second set of steps. I'm not changing what we do for (4) for now.

What should get stored in our prefs in terms of how to handle things in the future, given all that, is an interesting question.

Yeah. This is difficult. It's tempting to only store information where the extension is also the mimetype's primary extension, but unfortunately that breaks relatively common cases where a single mimetype commonly has one of several extensions (e.g. image/jpg and .jpg / .jpeg). I'm not changing pref storage in this bug. As noted in bug 393504, there's something to be said for storing the file extension in prefs too, but I'd like to limit the scope here.

Comment 1

[:Gijs (he/him)]

Attachment: Bug 1597985 - prefer file extension as provided over default extension for mimetype to look up default applications on Windows, r?bzbarsky

Comment 2

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/ed5828f8c8ed
prefer file extension as provided over default extension for mimetype to look up default applications on Windows, r=bzbarsky

Comment 3

[Andreea Pavel [:apavel]]

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

Comment 4

[:Gijs (he/him)]

Comment on attachment 9110267 [details]
Bug 1597985 - prefer file extension as provided over default extension for mimetype to look up default applications on Windows, r?bzbarsky

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration:
• User impact if declined:
• Fix Landed on Version:
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky):
• String or UUID changes made by this patch:

Comment 5

[:Gijs (he/him)]

Comment on attachment 9110267 [details]
Bug 1597985 - prefer file extension as provided over default extension for mimetype to look up default applications on Windows, r?bzbarsky

Let's not uplift this until we figure out the regression.