1520253 - .eml file in windows application fails to open correctly

Status: RESOLVED INCOMPLETE

(Thunderbird :: OS Integration, defect)

Description

[a.nenni]

Attachment: application eml link

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0

Steps to reproduce:

On Windows 7 64bit with a recent thunderbird client.
Open an eml file from within a windows application, checkpoint smartconsole in this case.

Actual results:

Message opens up incomplete, with no possibility to open or download attachment or see source.
"view source" points to an empty dir:

File non trovato
Non è possibile trovare view-source:file:///C:/Users/anenni/AppData/Local/Temp/Incidents/172.16.100.203_maildir_sent_new_time1547549562.mail-3868737440-4234084281.localhost__403912/172.16.100.203_maildir_sent_new_time1547549562.mail-3868737440-4234084281.localhost.eml?type=application/x-message-display. Controllare il percorso e riprovare.

Expected results:

Other email clients, like outlook 2013, the bat, or even internet explorer are able to access the eml file from the same temporary "Incidents" subfolders

An old seamonkey has the same issue

Comment 1

[a.nenni]

Attachment: eml file opened

Comment 2

[a.nenni]

Attachment: view source error

Comment 3

[a.nenni]

Attachment: download attachment error

Comment 4

[a.nenni]

Opening the same eml file from filesystem, with either a doubleclik in the folder or from thunderbid with "file > open" works just fine.

Comment 5

[a.nenni]

This is the console error trying to save the attached file:

[Exception... "Component returned failure code: 0x80520012 (NS_ERROR_FILE_NOT_FOUND) [nsIMessenger.saveAttachment]" nsresult: "0x80520012 (NS_ERROR_FILE_NOT_FOUND)" location: "JS frame :: chrome://messenger/content/msgHdrViewOverlay.js :: AttachmentInfo_save :: line 1851" data: no] (sconosciuto)
AttachmentInfo_save chrome://messenger/content/msgHdrViewOverlay.js:1851:5
actionFunction chrome://messenger/content/msgHdrViewOverlay.js:2721:50
HandleMultipleAttachments chrome://messenger/content/msgHdrViewOverlay.js:2725:11
HandleAllAttachments chrome://messenger/content/msgHdrViewOverlay.js:2610:3
TryHandleAllAttachments chrome://messenger/content/msgHdrViewOverlay.js:2622:5
oncommand chrome://messenger/content/messageWindow.xul:1:1

Comment 6

[Jorg K (CEST = GMT+2)]

(In reply to a.nenni from comment #4)

Opening the same eml file from filesystem, with either a doubleclik in the folder or from thunderbid with "file > open" works just fine.

So what do you want us to do? We don't know how your "windows application" opens the file, and we have no control over it.

I don't know how you got to view-source:file:// ..., TB doesn't use this to view the message source.

Comment 7

[a.nenni]

The "view-source:file://..." error is returned trying simply to open source with Ctrl+U, so nothing strange.

And my Windows application is also nothing exotic, it's Checkpoint Firewalls R80.10 SmartConsole series, any version

https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk119612

Since Outlook and the bat are able to open it, it's a bug, and it seems some OS integration issue with temporary file location

I suppose there are not hundreds of methods to open an eml file from a windows application.

If there's something more I can do to debug the error from withing Thunderbird please let me know.

Comment 8

[Jorg K (CEST = GMT+2)]

(In reply to a.nenni from comment #7)

The "view-source:file://..." error is returned trying simply to open source with Ctrl+U, so nothing strange.

It is strange, since TB doesn't use view-source: for displaying the source of any message within TB or went opened from an .eml file.

Since Outlook and the bat are able to open it, it's a bug, and it seems some OS integration issue with temporary file location

So if you switch your default mail client to Outlook or "The Bat!", your 3rd party application can successfully launch the e-mail program to show the message?

How do you expect us to debug this? We'd need to install your 3rd party application to check it ourselves? Why don't you contact the manufacturer of that software and file a bug with them? Windows can open .eml files, so how do we know where the problem lies?

Comment 9

[Mike Kaganski]

I would suspect that the calling application stores the .eml to a temp storage; launches associated application; (possibly waits some time,) and removes the .eml. Which would be the reason for the NS_ERROR_FILE_NOT_FOUND and all around this. The possible differences with regards to other email programs could be that those other programs could lock the file on disk; or possibly the API that is used by the calling application is implemented in those email programs as blocking ("modal") (highly unlikely IMO); or that the calling application waits for launched process to exit, and in case of TB already running in the background, the secondary launched TB passes the command line to primary process and exits...

Comment 10

[Jorg K (CEST = GMT+2)]

Thanks for the comment, Mike. Following this train of thought, reporter, can you check that the .eml file is really available at the location shown in the message, so C:\Users\anenni\AppData\Local\Temp\Incidents\ etc. etc.

Comment 11

[a.nenni]

I did open a case also with Checkpoint, that is ongoing, but if all other microsoft and third party email clients work, who do you think they'll blame for the bug if not thunderbird?

Anyway Mike ipothesys seems to catch the point.
With thunderbird I see subdirectory and file compare for about a second, and then they disappear.

Whatever other program I associate with eml files, including not only outlook and thebat, but also notepad and internet explorer, the file stays there all the time that the client is open.

Comment 12

[a.nenni]

Another confirmation of Mike comment.

If I close the smartconsole windows app while the eml file is open in a client that works, it remains there forever.

Comment 13

[a.nenni]

If you need a hint on a working API being used, I can make some tests with an some open source text editor windows program associated to the EML format, so that you can take a look at the relevant code.

Comment 14

[a.nenni]

The first open source program I tried, latest notepad++ 64bit, work just fine, holding the temporary file in place until it is closed.
So you can simply check the used API in the source code.
If you prefer a specific alternative program let me know.

Comment 15

[Wayne Mery (:wsmwk)]

a.nenni, do you still encounter this problem?