On Windows use extraMimeEntries and defaultMimeEntries to map mimetypes to extensions if registry lookups fail (in favour of extension provided as input)
Categories
(Firefox :: File Handling, defect, P3)
Tracking
()
People
(Reporter: evilpie, Assigned: Gijs)
References
Details
On Windows at least we don't actually use the extraMimeEntries to enhance the information returned by nsExternalHelperAppService::GetFromTypeAndExtension.
See bug 1690051 comment 8 for a detailed description.
|
Assignee | |
Comment 1•4 years ago
•
|
||
(In reply to Tom Schuster [:evilpie] from comment #0)
On Windows at least we don't actually use the extraMimeEntries to enhance the information returned by
nsExternalHelperAppService::GetFromTypeAndExtension.
We do, but too late (namely in the platform-agnostic code), and can end up with nonsensical extensions provided by the server instead.
This is specifically about the code at https://searchfox.org/mozilla-central/rev/b2433a832c250c55255e0ee37d05192d04f20427/uriloader/exthandler/win/nsOSHelperAppService.cpp#450-454 which attempts to get a file extension that fits the mimetype. This code does not use the builtin mimetype-to-extension mappings, relying only on the registry.
|
|
Assignee | |
Comment 2•4 years ago
|
||
I'll see if I can fix this in the next week or so.
|
Reporter | |
Comment 3•4 years ago
|
||
Seems likely that after we implement this we will get a lot more reports where we change the extension unexpectedly.
|
|
Assignee | |
Comment 4•4 years ago
|
||
(In reply to Tom Schuster [:evilpie] from comment #3)
Seems likely that after we implement this we will get a lot more reports where we change the extension unexpectedly.
Only for types where we change the extension and Windows doesn't ship with registry info indicating an extension for that same mimetype. That's gotta be a pretty small list.
Description
•