Closed Bug 226927 Opened 21 years ago Closed 21 years ago

PDF file attachment corruption

Categories

(Thunderbird :: Message Compose Window, defect)

Product:
Thunderbird
Component:
Message Compose Window
Platform:
PowerPC
macOS
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
Thunderbird0.4

People

(Reporter: adam.lent, Assigned: Bienvenu)

Details

Attachments

(1 file)

force attach_binary to true
776 bytes, patch
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5) Gecko/20031026 Firebird/0.7
Build Identifier: 

All builds subsequent to 20031111 cause corrupted PDF attachments, which contain
form fields.  Mail recipient receives an error upon opening attachment, within
Acrobat, “There was an error processing a page.  There was a problem reading
this document (114)”  This does not occur with build 20031111 and older.

Reproducible: Always

Steps to Reproduce:
1.Attach PDF file containing form fields
2.Send mail
3.Open attachment contained within received mail

Actual Results:  
Acrobat reports an error reading document.
When attempting to open sent PDF attachment on Mac platform, the following results:

“There was an error processing a page.  Too few operands.”
“An unrecognized token ‘2782f’ was found.”

The above is reported by Acrobat, for Mac, when attempting to open attachment.

Simple PDF file attachments do not exhibit this problem.  As indicated before,
this problem did not exist with builds 20031111 and older.
question, if you view source on the message, do you see the text "This mime part
will be downloaded on demand"? 

Can you tell if the attachment is binhex encoded by looking at view source as well?

Content-Type: multipart/mixed; boundary="------------010007070407090001080801"
This is a multi-part message in MIME format.
--------------010007070407090001080801 Content-Type: text/plain;
charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit

Content-Type: application/mac-binhex40; x-mac-type="50444620";
x-mac-creator="4341524F"; name="XYZ.pdf" Content-Transfer-Encoding:
quoted-printable Content-Disposition: inline; filename="XYZ.pdf"

The above is from the message source of an attachment that exhibits the problem.


This is a multi-part message in MIME format.
--------------030107070906040606060807 Content-Type: text/plain;
charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit

Content-Type: application/mac-binhex40; x-mac-type="50444620";
x-mac-creator="4341524F"; name="YYZ.pdf" Content-Transfer-Encoding: base64
Content-Disposition: inline; filename="YYZ.pdf"

The above is from the message source of an attachment that does NOT exhibit the
problem (within the same build).

I do not see the text "This mime part will be downloaded on demand".
The attachment that does NOT work, appears to be missing the base64
Content-Transfer-Encoding.
The same PDF attachment that fails in builds above 20031111 was successfully
sent in 20031111 and its message source confirms: “Content-Transfer-Encoding:
base64 Content-Disposition: inline;“.  The encoding is missing in subsequent builds.
In fact the current builds that do NOT work are showing:
“Content-Transfer-Encoding: quoted-printable“
To summarize things if I understnad them correctly.

Builds before 11/11 properly use base64 encoding.

The broken builds list the encoding of the attachment as quoted printable and
not base64.

cc'ing bienvenu as this looks remarkably similar to Bug #168098 which he fixed
in the 1.5b time frame.
Status: NEW → ASSIGNED
Target Milestone: --- → Thunderbird0.4
I have a vague recollection of someone checking in a change to the code that
detects if attachments are binary or not - I'll investigate.
The 20031111 build (and previous to) was the last that successfully worked.  And
yes, use base64 encoding.  All subsequent to 11/11 are broken.
The only recent change to content type sniffing that I have found during the
time period in question so far is:

http://bugzilla.mozilla.org/show_bug.cgi?id=126782
taking for investigation.
Assignee: mscott → bienvenu
Status: ASSIGNED → NEW
I'm not able to reproduce this problem. This only happens on some .pdf files? If
so, can you e-mail me or attach a .pdf file that has this problem? Does every
.pdf file you send get sent as quoted-printable, or only some of them? This
might be mac-specific but I hope not (since I don't have a mac here)
This does not occur with all PDF attachments.  Simple PDFs, such as from
creating a PDF from a Word document, do not exhibit the behavior.  PDFs that
contain form fields do exhibit this problem.  I would believe that this is a
platform independent issue.  I will send to you a PDF (with a build that works,
20031111) and I will then send the same file from a current build.  You will be
able to open the 20031111 attachement, but the current build’s attachment will
show the error.  If you attempt to attach the working file to a current build
and send it, you should see it being sent as “quoted-printable”.  If not, it’s
likely a Mac specific problem.  I will send this file directly to your email
address.
I tried this on windows with a tip mozilla build and a recent thunderbird build,
and it worked fine. I'm going to make sure my thunderbird build is really up to
date and try again. But right now, I'm starting to suspect this is particular to
your profile or mac-specific.

Can you try setting the pref "mail.file_attach_binary" to true, and see if that
fixes the problem for you?
I have not changed my profile going forward and back from the 20031111 build
(from the 2003-11-10-trunk).  I have looked for the pref
"mail.file_attach_binary", in the prefs.js file.  It is not present in this file
in my Thunderbird library folder.  Did the PDF file I sent to you with the
20031202 build exhibit the error I reported?  Did it show quoted-printable in
its source?  Why would the 20031111 build encode as base64 for the same PDF file?
the default for that pref is false; that's why it's not in your prefs.js (we
only write non-default prefs into prefs.js). So if you add it to your prefs.js
as true, it might change the behaviour.

By something profile-specific, I meant something profile-specific that triggers
the regression you're seeing, not that it's only caused by your profile.

Yes, the files you sent me showed the problem. The problem is that we should not
be picking quoted-printable at all for that attachment. Changing that pref
bypasses some of the content-sniffing code, and the results will let me know
better where the code is going wrong.
Inserting “mail.file_attach_binary“ as true, fixes the problem exhibited with
the PDF file attachment.  It now encodes as base64.  Is this a band-aid or a
resolution?  Is there any harm in attaching other file types in base64 only?
frankly, I'm strongly tempted to make this the default behaviour. The only harm
is for mail recipients who don't have modern e-mail clients who get text
attachments which aren't 7-bit clean, but are "mostly" clean, - the idea is that
 quoted-printable is somewhat human readable, whereas base64 is not.
I will no longer be able to see if a true fix for this problem has been
implemented, unless I turn off the default encoding.  Is there a way for me to
be notified when a possible fix has been implemented (in a future build) so I
can turn off the force encoding and test the fix?  Or is this not going to be
resolved in lieu of the force encoding work-around?  Please advise.
At the very least, you'll get bug e-mail when the status changes. If we don't
just change the default pref but try to figure out what's going wrong, you'll
hear from me earlier unless I can figure out how to reproduce this problem :-)
fixed for the 0.4 release by changing our default pref. I'll try to remember to
release note this so power users can turn it off again if they want.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: