[Description:]

Due to changes in bug 1710926, now as part of adding a new mime type the file must be opened. This generates a different path than with the old method, which in case of .docx extension i think results in opening with WordPad prior to adding the docx extension to the mime list.

[Environment:]

Windows 10
not reproducible - Mac 11
96.0a1 2021-11-12

[Steps:]

1. Download a docx from https://filesamples.com/formats/docx#google_vignette
2. Wait for download to finish.
3. Right click on the downloaded file and select "Always Open Similar Files"
4. Navigate to about:preferences / Applications and verify the entry.

[Actual Result:]

docx is labeled as OOXML Text Document

[Expected Result:]

docx should be labeled as Microsoft Word (Open XML)

[Note:]

1. doc is labelled as Microsoft Word
2. Altough the "OOXML Text Document" is not incorect, i believe it would be rather confusing

[Severity:]

Even though in all honestly this issue is S3 material, I'm setting it on S2 pending additional investigation, since it is possible that some other content types might've been changed in Fx96 and a root cause analisys for this issue might reveal the root cause.

:gijs, can you please also confirm that the difference in the wording (check the screenshot):
Fx96 - Use WordPad(Default)
Fx94 - Use Windows WordPad Application - had no Default on Windows

(In reply to Adrian Florinescu [:aflorinescu] from comment #1)

Created attachment 9250520 [details]
docx.jpg

:gijs, can you please also confirm that the difference in the wording (check the screenshot):
Fx96 - Use WordPad(Default)
Fx94 - Use Windows WordPad Application - had no Default on Windows

Did you check these on the same machine? Because I suspect not - we try to read a human-readable description of the filetype from the registry, and that's why the difference might exist between different machines (e.g. depending on whether MS office software has ever been installed, or the Windows version). I don't think that has changed between 96 and 94, but if it has a detailed regression window would be helpful, as would knowing if setting the improvements_to_downloads_panel pref to false makes any difference.

The results are on the same machine, no Office installed.

Found commit message:
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.

Differential Revision: https://phabricator.services.mozilla.com/D130526

The windows default Application by file type lists the description as "Office Open XML document".

Okay, I see what's happening here. "OOXML Text Document" is what you find in the registry if you look up the file extension ".docx", because that's what the initial registry that's created during OS installation has in it. But prior to bug 1738111 we didn't have a file extension to look up, so we consulted our own built-in list of fallbacks, which contains the description string you're seeing from 94.

So now, I kind of don't feel like we should fix this? It doesn't seem like a good policy to be deliberately overriding the descriptions given by the app we're going to use to run the file just because we think ours are better. Gijs, second opinion?

(In reply to Molly Howell (she/her) [:mhowell] from comment #5)

Okay, I see what's happening here. "OOXML Text Document" is what you find in the registry if you look up the file extension ".docx", because that's what the initial registry that's created during OS installation has in it. But prior to bug 1738111 we didn't have a file extension to look up, so we consulted our own built-in list of fallbacks, which contains the description string you're seeing from 94.

So now, I kind of don't feel like we should fix this?

I concur with this, I don't think this is worth specifically addressing.

It doesn't seem like a good policy to be deliberately overriding the descriptions given by the app we're going to use to run the file just because we think ours are better. Gijs, second opinion?

Weeeeellll. We have other reasons to want to do something like this (ie relying on our own mimetype-to-extension mapping in favour of extensions provided by the server), x-ref bug 1690539 and bug 1690051 comment 8 . "ours are better" is pretty much true when it comes to the rubbish the internet tends to provide us with, plus I kind of think "Microsoft Word (Open XML)" is a more useful description than "OOXML document" but OK. Basically the whole thing is a mess and needs a rethink, but I definitely agree there's no point trying to fix this issue as filed.

As previously stated in our latest sync, I'm fine with the resolution and the points made so far with the only one small argument that in current format what the OS gives us might end up being sometimes between confusing and unusable. Therefore, since agreeing that we shouldn't do anything extra with what the OS gives us, at least at this point, I am strongly advocating that we should make sure we are exposing the extension in the content type - ofc, where this information is not provided and it makes sense having it.

Later edit: added bug 1742561 for the above.