1361278 - Some PDF attachments cannot be opened through IMAP

Status: RESOLVED DUPLICATE of bug 1355350

(Thunderbird :: Untriaged, defect)

Description

[TomasS]

Attachment: scan.eml

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:53.0) Gecko/20100101 Firefox/53.0
Build ID: 20170418122848

Steps to reproduce:

Open attached PDF file from a message that is accessed via IMAP.

(The problem started to occur in TB 52. Works fine when downgrading to 45.8.0 or when the message is saved as EML do disk and opened from there. So in order to reproduce this issue, you have to import this EML to an IMAP folder and try to open it.)


Actual results:

Acrobat Reader DC (17.009.20044) prints: "There was an error opening this document. The file is damaged and could not be repaired."


Expected results:

The PDF should be downloaded and opened in its full beauty.

Comment 1

[buovjaga]

I imported to an IMAP folder and opened the PDF OK.

Thunderbird 52.1.0 (32-bit)
Windows 7 64-bit

Comment 2

[TomasS]

Another thing I noticed is that the attachment can be opened when I click "Forward" and open the attachment from the new message window.

Comment 3

[TomasS]

I have identified this problem exists only when an email account has synchronization (offline copies) turned off. I usually turn this feature off so my roaming profiles don't get too big.

Comment 4

[Wayne Mery (:wsmwk)]

can you try nightly build from https://archive.mozilla.org/pub/thunderbird/nightly/latest-comm-central/thunderbird-55.0a1.en-US.linux-x86_64.tar.bz2

Comment 5

[Jorg K (CEST = GMT+2)]

Yes, that sadly happens when the folder is not synchronised for offline use.
We've written it into the release notes:
https://www.mozilla.org/en-US/thunderbird/52.0.1/releasenotes/
https://www.mozilla.org/en-US/thunderbird/52.1.0/releasenotes/, 52.1.0 available now.

You can either try the workaround or use TB 54 beta. That hasn't been published yet, but you can get an unofficial version here:
https://archive.mozilla.org/pub/thunderbird/tinderbox-builds/comm-beta-win32/1493460706/

Daily/Nightly build also work.

Comment 6

[TomasS]

(In reply to Jorg K (GMT+2) from comment #5)
> You can either try the workaround or use TB 54 beta.

Funny thing is I already tried the workaround mentioned in release notes and it didn't help.

(In reply to Wayne Mery (:wsmwk, NI for questions) from comment #4)
> can you try nightly build

Nightly build works fine so I am looking forward to next releases.

Thank you guys for your effort.

Comment 7

[Jorg K (CEST = GMT+2)]

(In reply to JanK from comment #6)
> Funny thing is I already tried the workaround mentioned in release notes and
> it didn't help.
Really? Did you *create* the integer preference browser.cache.memory.capacity?
You can also try preference browser.cache.memory.max_entry_size set to the value of 25000 instead of -1.

The official version uses:
pref("browser.cache.memory.max_entry_size", 15000); //  15 MB
pref("browser.cache.memory.capacity",      120000); // 120 MB = 8*15 MB
but it also has code tweaks that go with it.

Comment 8

[TomasS]

(In reply to Jorg K (GMT+2) from comment #7)
> Really? Did you *create* the integer preference
Yes indeed, I created it. I even double-checked it is the right type (integer).

(In reply to Jorg K (GMT+2) from comment #7)
> You can also try preference browser.cache.memory.max_entry_size set to the
> value of 25000 instead of -1.
That did nothing to me too.

Just to be clear I tested this right now with 52.1.0 - Win32. No luck. So maybe it were some other code changes that did the trick.

Comment 9

[Jorg K (CEST = GMT+2)]

Yes, there were other code changes for other aspects of the problem. I thought that lifting the limits actually avoided the other aspects. Thinking about it now, there was one thing that lifting the limits wouldn't have fixed.

Well, as long as it's fixed in Daily and the forthcoming TB 54 beta, we're OK. Please let me know if you see other problems.