1609318 - Weird detection of .eml file type. (only opens if .eml extension)

Status: NEW

(Thunderbird :: OS Integration, enhancement)

Description

[Volker Weißmann]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:72.0) Gecko/20100101 Firefox/72.0

Steps to reproduce:

1. Save a valid .eml as testext.eml and testnoext (without a file-extension).
2. run one of the following commands:
   $ thunderbird "$PWD/testext.eml"
   $ thunderbird testext.eml
   $ thunderbird "$PWD/testnoext"
   $ thunderbird testnoext

I tested it on a machine with the user following Agent:
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.3.1

Actual results:

$ thunderbird "$PWD/testext.eml"
Thunderbird starts and displays the email.

$ thunderbird testext.eml
Thunderbird starts and displays the email.

$ thunderbird "$PWD/testnoext"
Thunderbird starts and want so send a new email with the testnoext file as an attachement.

$ thunderbird testnoext
This command send the following text to stderr an exits with exit code 0:
JavaScript error: , line 0: uncaught exception: 2147500037
JavaScript error: resource://gre/modules/ExtensionSettingsStore.jsm, line 117: Error: The ExtensionSettingsStore was accessed before the initialize promise resolved.
JavaScript error: resource://gre/modules/ExtensionSettingsStore.jsm, line 117: Error: The ExtensionSettingsStore was accessed before the initialize promise resolved.
JavaScript error: resource://gre/modules/ExtensionSettingsStore.jsm, line 117: Error: The ExtensionSettingsStore was accessed before the initialize promise resolved.
JavaScript error: resource://gre/modules/ExtensionSettingsStore.jsm, line 117: Error: The ExtensionSettingsStore was accessed before the initialize promise resolved.
JavaScript error: resource://gre/modules/ExtensionSettingsStore.jsm, line 117: Error: The ExtensionSettingsStore was accessed before the initialize promise resolved.
JavaScript error: resource://gre/modules/ExtensionSettingsStore.jsm, line 117: Error: The ExtensionSettingsStore was accessed before the initialize promise resolved.

Expected results:

All of these four commands should start Thunderbird and display the email.

Why do I think so?:
The linux "file" command detects both testext.eml and testnoext as:
"SMTP mail, ASCII text, with CRLF line terminators". Therefore "xdg-open testnoext" and double clicking on a testnoext in a file manager executes the command
$ thunderbird "$PWD/testnoext", which does not result in thunderbird displaying the email (but it should result in thunderbird displaying the mail). This means that if you are naive and think "I don't need file name extensions, there are magic numbers in the file." and rename a valid .eml file to something without an extension, you can no longer display the email by double-clicking it in a file manager. This might confuse non-techy users who aren't familiar with the concept of file extensions. (Happened to someone who called me to help yesterday.)
If you think that this is his fault for removing the file extension, please note that most linux applications ignore file extensions and just check for magic numbers. E.g evince can open a pdf file even if it has no .pdf extension and file-roller can open a zip fle even if it has no .zip extension.

Comment 1

[Magnus Melin [:mkmelin]]

This is per design, we only want to open .eml named files.

Comment 2

[Volker Weißmann]

Why don't you want to open eml files without the extension?

Comment 3

[Magnus Melin [:mkmelin]]

Hm, yeah maybe I was too quick in closing this. Want to make a patch? You should be able to use nsIMIMEService getTypeFromFile and hook it in here: https://searchfox.org/comm-central/rev/258c28a105511491efbfc274a392e90d82eeefce/mail/components/MessengerContentHandler.jsm#365

Comment 4

[Volker Weißmann]

Thank you for considering it. If nobody else wants to write the fix, I will do it, but it will cost me more time to do it than someone who is familiar with the source code of Thunderbird. I think I wait for two weeks or so and if no one has fixed it yet, I will do it.

Comment 5

[Volker Weißmann]

I am not going to fix this bug, because I do not have enough time. Because this bug is not a mission-critical bug and not a very complicated bug, I would say that we leave this bug open for any programmer searching for easy things to fix.

Comment 6

[Ping Chen [:rnons] (away)]

(In reply to Magnus Melin [:mkmelin] from comment #3)

Hm, yeah maybe I was too quick in closing this. Want to make a patch? You should be able to use nsIMIMEService getTypeFromFile and hook it in here: https://searchfox.org/comm-central/rev/258c28a105511491efbfc274a392e90d82eeefce/mail/components/MessengerContentHandler.jsm#365

I tried to use getTypeFromFile, but got NS_ERROR_FAILURE: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE [nsIMIMEService.getTypeFromFile], then I found getTypeFromFile relies on file extension as well.

No attempt to determine the type via server headers or byte scanning is made.

https://searchfox.org/mozilla-central/source/netwerk/mime/nsIMIMEService.idl#56-57
https://searchfox.org/mozilla-central/source/uriloader/exthandler/nsExternalHelperAppService.cpp#2722

Comment 7

[Magnus Melin [:mkmelin]]

Ah, then this would be much more complex...