459474 - Cannot open some PDF attachments

Status: RESOLVED FIXED

(Thunderbird :: Mail Window Front End, defect)

Description

[Peter Ashford]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.0.3) Gecko/2008092417 Firefox/3.0.3
Build Identifier: version 2.0.0.17 (20080914)

Problem started several months ago - formerly no problem.

Attempting to open PDF attachment shows Download Error: "Can't open etc. . . change association in preferences".

But that reads OK: "PDFs" - Action: "Open with Adobe Reader 9.0".  So, no reason why it doesn't do so.

Always have to save attachment to desktop then open with Adobe Reader 9.0 with no problem    

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Comment 1

[Ludovic Hirlimann [:Usul]]

Peter can you follow and read http://kb.mozillazine.org/Actions_for_attachment_file_types , there is a troubleshoot section can you follow it and tell me if it helps ?

Comment 2

[Peter Ashford]

Thanks but problem remains.  Sent PDF attachment to my self and, per troubleshooting guided recommended shows exactly as example Content-Type: application/pdf;

name= "test.pdf"

That would not open with left click (get Download Error statement).  Using Right click gives only two choices:  Open, or Save As.

In the Downloads Actions list it shows correctly:

PDF / Adobe Acrobat Document /  (open with) Acrobat Reader 9.0

When I save I can immediately open with AR 9.0!

No problems with JPGs etc, the other 'open-withs' work OK.

Regret no progress.

Comment 3

[Ludovic Hirlimann [:Usul]]

Sorry for the delay. Anything in Tools -> Error console ?

Comment 4

[Peter Ashford]

About 30 warnings in Error Console, nothing else except warnings. All undated. Entries have no meaning to me.
Noted text of 1st and last entries the sent PDF attachment to myself.  Unable to open as usual.
Re-checked Error Console - no new entry was created.
Regards.

Comment 5

[[:Aureliano Buendía]]

A radical workaround should be to delete MimeTypes.rdf file in you rpofile foder (see http://kb.mozillazine.org/MimeTypes.rdf).

If you use latest beta you can change this from TB
http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-comm-1.9.1/ ?

Comment 6

[Thomas D. (:thomas8)]

I am experiencing this bug on
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.5) Gecko/20091211 Lightning/1.0pre Shredder/3.0.1pre

- My feeling is that this stopped working only very recently (a week or so) -> regression?
- Other types of attachment work (e.g. double-click excel.xls file will prompt what to do).
- the pdf file if saved is perfectly ok and TB also recognizes the format, showing correct pdf icon in attachment panel
- I am not aware of having changed anything, just running Shredder as usual

STR
1 Have these settings (default?): Tools > Options > Attachments:
- about: always ask
- Word doc: always ask
- Always ask me where to save files (enabled)
2 a (received) mail with a valid pdf attachment (correct icon)
3 double click on the attachment

Actual result
- nothing (Status bar shows something for less than a second, maybe "downloading")
where nothing means nothing, no question, no saving, no opening.
In other words, I am forced to save attachment to view it.

Expected
- TB should ask me what to do with this file (open with/save)

Not sure if I should confirm as symptoms in comment #0 are slightly different.
Any information on this problem or what might have caused it? Recent patches?

Comment 7

[Ludovic Hirlimann [:Usul]]

Thomas you might have a corrupted mimestypes.rdf file. Anything in Tools -> Error console when you encounter the issue ?

Comment 8

[Thomas D. (:thomas8)]

No, nothing in the error console.

But other emails with pdf attachments from same company work fine (dialogue on double-click attachment). So it must be message-related. Weird though, correct icon and correct saving of a correct pdf file, just double-click on pdf-attachment does nothing on that first mail (the status bar says: "Downloading message", does that help?). Very similar behaviour to comment 2.

I'll send Ludovic a copy of the message for analysis.

Comment 9

[Amber]

I use Thunderbird to send e-mails, including attaching PDF files for ad proofs to clients. Recently, including today, I have had clients call me and tell me that they are unable to open the PDF file attachment. They are all different types of accounts, including hotmail. If I turn the PDF file into a JPG they are able to open the JPG. Some clients can open their attached PDF files while others can't.

I am on a Mac. This problem has happened with recipients being on both Mac and PC.

I have not done anything different in creating my PDF files, my settings are all the same. The only thing that has changed recently was upgrading Thunderbird. I determined that it was a Thunderbird problem.

I tested this theory this morning. I sent a PDF file as an attachment through Thunderbird. My client was not able to open it. So I logged in directly to my e-mail provider account (frontier webmail) and sent the exact same file as an attachment uploaded through the web. The client was able to open the exact same PDF file this way.

This is a major problem that needs to be fixed. If my clients cannot open their proofs attached to their e-mails I will be forced to use abandon Thunderbird and use a different e-mail client.

Comment 10

[David :Bienvenu]

Amber, can you send me a pdf attachment that others can't open? I assume the others are using a mix of e-mail clients.

Comment 11

[Thomas D. (:thomas8)]

Confirming for
Earlybird 8.0a2 2011-08-19

It's message-related, works fine on some messages, still doesn't work on the test msg that I sent to Ludovic per comment 8. But saving the file from the non-working message and then viewing it from download manager works fine, so the message as such is not corrupted, so it appears to be a TB problem.

Comment 12

[Andrew M.]

I confirm this bug still occurs with the public last release of TB downloaded last week. Doubleclicking the attachment icon, or right clicking it and picking "open", does nothing.

I suggest 539854 is a duplicate of this bug, since it seems to be the same error regardless of the specific file type, and this bug is the earliest report of it that I can find.
Saying that is "message specific" is hardly helpful because receiving PDFs and DOCs from outlook users is a common use case for any email client today.

The dependency of 539854 should be removed, it should be marked as a duplicate of this bug 459474, and all votes on the importance of 539854 should be counted as making this bug 459474 more important. Unless you have a time travel machine, 539854 depends on this one, not the other way around.

It's been unresolved since 2008. Seriously. Thunderbird is *unusable* in its current release because of its inability to open attachments directly from email. As a user you would never put up with tedium like this in Outlook or Gmail or Eudora or Evolution. 

A similar bug was fixed in TB 2 in 2006:
 https://bugzilla.mozilla.org/show_bug.cgi?id=346332
Did someone at Mozilla like the bug so much they decided to reintroduce it? Maybe you could find the code from TB2 that actually worked and see what's different in trunk?

Critically defective for three years, yet opening attachments worked fine in TB 2.0 and in the original Mozilla suite email client in 2004. What a sad joke. 

Lifehacker recently promoted TB as the best email client for windows. I have emailed the author of that article at lifehacker to point out he could not have actually used TB and still write a glowing review about it because of this bug. Perhaps he will bring this bug to wider attention.

Comment 13

[David :Bienvenu]

The issue in the test case that a user gave us was that the content type of the attachment was incorrect; it was pdf instead of application/pdf. This isn't common since most mailers know how to set content types. But we should be able to handle it since we know the file extension. For some reason, by the time we get to opening the attachment, the uri is a message uri, and not a file uri, so we don't fall into the code that knows how to invoke the helper app. I'll look into it some more...

Comment 14

[David :Bienvenu]

Attachment: proposed fix

The issue is that "pdf" is not a valid content type at all, which means NS_ParseContentType can't parse it, which means we end up with a content type of message/rfc822 because nsMsgProtocol::GetContentType returns that for empty content types.

I could tweak this fix to only set the unknown content type if the original content type is not empty, though I don't think anyone is deliberately passing the empty string to SetContentType.

Once we have the unknown content type, all the uriloader code that figures out the content type from the file extension gets a chance to shine. And then we'll show the app helper dialog.

Comment 15

[Andrew M.]

I am going to have to look more closely at the content type and file extension of the attachments that won't open, at least for bug ticket categorisation. I may have been wrong in thinking the real bug matches this bug ticket description. I can't do this right now because the bug does not affect me directly, it affects another computer my family has. If it only affected me I would not have been so angry in my earlier comment. 

The real bug I'm talking about does not produce an error message at all. It just does nothing when you use either double-clicking, File | Open Attachment, or the right-click context menu Open. This is an email which was received with the old Mozilla suite email client, and then migrated to Thunderbird during the new Thunderbird install last week.

I searched for existing bug reports several different ways before deciding this bug was the closest match to what I have seen. Certainly other people have had a similar problem over the last 2 years on both Linux and Mac and no doubt on Windows too.
 * http://www.linuxquestions.org/questions/linux-software-2/cant-open-attachments-in-thunderbird-454328/
 * http://getsatisfaction.com/mozilla_messaging/topics/thunderbird_3_wont_open_attachments_without_saving_on_mac
 * http://ubuntuforums.org/showthread.php?t=1442764

I have just searched again for a bug about Thunderbird on Windows containing the words "open attachment" and of the 71 bug titles listed I looked at the descriptions of about 10 of them and still cannot find an exact match for what I have seen. But I cannot believe nobody has reported this before, since it has been a problem for at least 2 years, possibly 4 years depending on which bug ticket matches.

But I can dispel a few myths right now:
The problem is NOT because of the attachment type being empty.
The problem is NOT because of the attachment filename being empty.
The problem is NOT because of the file extension being in lower case versus upper case.
The problem is NOT because of the attachment being in a proprietary TNEF format.
How do I know? Because the same attachment in the same email still opens correctly from the old Mozilla suite email client that originally received it and which still works fine on Windows XP. There is no problem with the data to be solved here that Mozilla hasn't solved already.
Mozilla suite 1.7 email works better than the latest Thunderbird. That's the bottom line. 

If anyone can find an existing bug report which accurately matches my description above, I will apologise and transfer my descriptions and vote to the closest matching bug report.

Comment 16

[Andrew M.]

Hello again.

I have today had a chance to do a View Source on the message with the PDF that would not open in TB7.

Content-Type: application/pdf; name="September 2011 Newsletter.pdf"
Content-Description: September 2011 Newsletter.pdf
Content-Disposition: attachment; filename="September 2011 Newsletter.pdf";
        size=60726; creation-date="Wed, 07 Sep 2011 16:55:43 GMT";
        modification-date="Wed, 07 Sep 2011 16:58:31 GMT"
Content-Transfer-Encoding: base64

As you can see the email MIME content type is the correct one.
As I said, this attachment opens okay using Mozilla email 1.7.

What is very interesting is that I uninstalled TB7, then installed Thunderbird 3 (version string is "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15" ) to see if this also has the bug. No, it does not. :-O  In TB3 it prompts you to choose what to do with the PDF attachment and if you just click OK for the default action it opens in Acrobat Reader just fine.

At this time as a workaround I would advise other people experiencing this "won't open attachments" bug to uninstall TB7 and install TB 3.1.15, which seems to detect and use your current email archive and account settings OK.

Comment 17

[David :Bienvenu]

Andrew M, can you e-mail me or attach your mimetypes.rdf file? That's the other variable in the process of trying to figure out how to open an attachment.

Comment 18

[Mark Banner (:standard8)]

Neil said last night that he needs some steps to reproduce this, so if we can get some more information that would be useful in moving this forward.

Comment 19

[David :Bienvenu]

I can't find the test case, but essentially any mal-formed content-type would do, e.g., pdf instead of application/pdf, which is malformed because it doesn't have a '/' in the middle.

Comment 20

[Rich]

In the last 3 days I have experienced this issue receiving and forwarding pdfs in the range 0.9 to 5 MB in size using TB on one pc, whereas with TB on another pc there was no problem.  By using the web-based mail server instead of TB I was able to download an uncorrupted form of the pdf on the troublesome pc.  By comparing the TB-corrupted version with the uncorrupted version, using Notepad, it is possible (1) to check that the two files look the same at the beginning but not at the end, and (2) to execute in the uncorrupted version a "Find" based on a few characters - say 40 to 50 characters - copied from the end of the corrupted version.  Those characters are then found towards the end of the uncorrupted file, but not at the end itself - say 85 percent of the way through.  This reveals that the end of the file - a substantial amount - is missing from the corrupted version.  So something is causing the download of the file to appear to be complete but actually not be.  I agree this is a serious flaw in TB.

Comment 21

[Rich]

It might help if I also mention that (on the troublesome pc) the problem remains just the same if (1) the anti-virus software is temporarily disabled, or (2) TB is re-started with add-ons disabled.

TB version is 13.0.1.4548

Comment 22

[David :Bienvenu]

(In reply to Rich from comment #20)
> In the last 3 days I have experienced this issue receiving and forwarding
> pdfs in the range 0.9 to 5 MB in size using TB on one pc, whereas with TB on
> another pc there was no problem.

that's fixed by the fix for Bug 92111, which will be in tb 16.

Comment 23

[Rich]

I also agree there is something not quite right about the download process.  When the option "Save" is selected, no progress bar appears.  Neither does any other indicator of how long one should be waiting for the download to complete.  It seems to be very quick.  This is not the normal situation.  Could it be that the download itself (as distinct from the saving or opening process) is occurring altogether prematurely (perhaps only to a partial degree, hence the chopped-off file length) - and not waiting until initiated in the normal way?  To test this idea I watched the "Networking" tab in Windows Task Manager.  When saving or opening in TB, Windows Task Manager reveals zero network activity.  When saving or opening the file via the web-based email server there is a huge spike in network activity for the duration of the download.

Comment 24

[David :Bienvenu]

The message is in the offline store for the folder, so we don't have to download it from the server. But it's incomplete in the offline store, because the server reported an incorrect size for the message.

Comment 25

[Rich]

Please tell me (and all users of TB) what TB setting I have to change to prevent this "offline store" being used in the first place.  Surely I'm entitled to control over if and when I do and do not try to download an attachment.

Comment 26

[David :Bienvenu]

right click on folder, select properties, synchronization tab, uncheck the box that says "keep messages for this folder offline". You can also use the properties dialog, general tab, to clear the offline store by clicking the repair button, which will redownload all the headers, and clear the offline store.

Comment 27

[Rich]

Please understand it's the attachments I have a problem with being stored blindly, not the email messages themselves.  I suspect there might be a number of people who would agree with me this is a major issue.

Comment 28

[Rich]

I'm so taken aback by this idea that attachments are being stored blindly on my machine that other things are only beginning to dawn on me.  It helps explain why TB takes literally FOR EVER to go through its synchronizing paces.  It's must be because it's synchronizing all those attachments.  What a huge waste of time and disk space.

Another thing which there needs to be separate control over for this "offline store" is what TB refers to as "Remote Content".  I also need control - separate control - over whether Remote Content is saved locally.  Just because I might choose to view Remote Content in a particular email does not mean I want that Rmote Content saved.  I might, or I might not.

Comment 29

[David :Bienvenu]

attachments are parts of messages; they're not separate things. They almost always come at the end of the message, which is why if the server tells us the message is smaller than it is, the end of the attachment gets chopped off. Remote content is not part of the message (assuming you mean things like links to remote images) and thus is not stored in the offline store with the message. It may be stored in the disk cache, however, if you choose to view them, just like images in a web page are stored in a disk cache in a browser. You can clear the disk cache as well, if you like, in options, advanced, network and disk space.

Comment 30

[Rich]

I appreciate your pursuing this with me.  I don't know if this is the best forum to be using for the part of the subject which relates to the overall design goals for TB.  There's clearly something to what you are saying.  Perhaps "separate" is the wrong word.  The attachments must at least be "distinguishable".  I have a really hard time with the idea that the email client software is downloading any attachment before I've asked it to.  I maintain this is a real issue.  Surely it must be possible to download just the message and stop there - regardless of whether the attachment is truly at the end (normal location as you say) or not.  This reminds me of a similar complaint I had about TB with the treatment of "signatures".  I have a hard time with the idea that anyone can tell what technique was used to add a "signature" to an email.  The result is that I am super careful to never use the signature capabilities of TB.  I always manually copy and paste-in that part from a text file - when I need more than just my name.  Someone at a high level at Mozilla is making decisions which take the control of these very basic design issues out of my hands, and can tell you I don't like it.  And I particularly dislike that these things only come out in the course of discussion of some other issue which at first seems innocuous and isolated.

Based on what you told me I have gone back to my email service provider (not AOL actually, even though I'm using an AOL account for this forum) and complained about the wrong reporting of file size information on their servers.  My guess - but it's only a guess - is that they're using some form of compression algorithms for attachments, most likely different ones for different recognizable types of files.  When it comes time to report the file size they possibly haven't paid enough attention to that detail and they perhaps report the compressed size instead of the uncompressed size.

Comment 31

[Wayne Mery (:wsmwk)]

Peter, Thomas, (or anyone else who sees the issue)
can you supply a testcase message and attach to bug please (as a file)?   
ref: comment 18

Comment 32

[Rich]

In response to the email received 2012-09-01 (request for test-case pdf) I went back in my INBOX and tried again opening the same series of pdf attachments which had given a problem on 2012-07-13 (see my comment 20 above).  This time I experienced no problem with them.  I also saved one of them on 2012-09-02 and used the Notepad comparison procedure in comment 20 to compare it with the version of the same file downloaded on 2012-07-13.  The 2012-09-02 file is complete (contains an END OF FILE marker) and its size as revealed by "properties" now matches the size stated in the email to which it was attached (926 KB in this case).  Also the Notepad comparison method reveals that both the beginning and the end of the file saved 2012-09-02 precisely match the version downloaded using the web-based mail server instead of TB.  The version of TB I am currently using is 15.0.

Comment 33

[Thomas D. (:thomas8)]

Attachment: Testcase1.eml (malformed content-type:pdf;)

(In reply to Wayne Mery (:wsmwk) from comment #31)
> Peter, Thomas, (or anyone else who sees the issue)
> can you supply a testcase message and attach to bug please (as a file)?   
> ref: comment 18

Here's a reduced testcase derived from my original testcases mentioned in comment 8, comment 11 (based on which this was confirmed).

With more knowledge about multipart msgs, I now found that the failure of testcase 1 is due to malformed content type.

Testcase 1 (fails on TB16.0.1/WinXP) with malformed
> content-type: pdf;

That's exactly what David :Bienvenu talked about in comment 19, and I suspect it's a kinda frequent malformedness, so we should be more tolerant when receiving.

Double-clicking on attached test.pdf does nothing, although the file itself is perfectly ok and can be opened after saving manually. Doing nothing without complaining is wrong.

Imo TB should derive the correct content-type from the file extension (.pdf), especially for the frequent and unambiguous case of pdf. Do we have a bug for that?

Comment 34

[Thomas D. (:thomas8)]

Attachment: Testcase2.eml (tolerated content-type:application/octet-stream)

testcase 2 works on TB 16 (need to revisit bug 453805), as TB tolerates frequent (non-standard)
> content-type: application/octet-stream

Comment 35

[Thomas D. (:thomas8)]

Attachment: Testcase3.eml (correct content-type:application/pdf;)

testcase 3 with correct and working
> content-type: application/pdf

Comment 36

[Wayne Mery (:wsmwk)]

(In reply to Mark Banner (:standard8) from comment #18)
> Neil said last night that he needs some steps to reproduce this, so if we
> can get some more information that would be useful in moving this forward.

Neil, are the above testcases sufficient to proceed with patch rewview?

Comment 37

[[e-mail]]

Comment on attachment 564989 [details] [diff] [review]
proposed fix

>+    m_ContentType = UNKNOWN_CONTENT_TYPE;
Nit: .AssignLiteral (both times).

Comment 38

[Ludovic Hirlimann [:Usul]]

(In reply to [e-mail] from comment #37)
> Comment on attachment 564989 [details] [diff] [review]
> proposed fix
> 
> >+    m_ContentType = UNKNOWN_CONTENT_TYPE;
> Nit: .AssignLiteral (both times).

Aceman can you provide the proper patch for this so we can land this ?

Comment 39

[:aceman]

Yes.

Comment 40

[:aceman]

Attachment: updated fix

Comment 41

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/comm-central/rev/3220cc71d137

Can the attached testcases be landed as automated tests?

Comment 42

[:aceman]

Can anybody confirm the patch hes helped to fix the testcases and did not broke other valid attachments?

Comment 43

[Mark Banner (:standard8)]

At the moment, I don't think we want to take this on 17. I'd rather this ride the trains and go out with 24 so that we've had plenty of time for testing and checking we haven't broken valid attachments.

Comment 44

[Adex]

Hello,
I'm using Thunderbird 31.1.1 and Windows XP SP3, and some emails with PDF attachments can't open. 
Save PDF attachment to directory and open works OK!

Files created in TEMP directory got some weird HTML code inside (from email I think)

Anyone got clue whats going on?