Closed Bug 65794 Opened 24 years ago Closed 16 years ago

Some attachments (like text/plain, text/html) get Content-Disposition: inline (incorrect)

Categories

(MailNews Core :: MIME, defect, P1)

Product:
MailNews Core
Component:
MIME
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
Thunderbird 3.0a3

People

(Reporter: m_kato, Assigned: mkmelin)

References

(Depends on 1 open bug, Blocks 1 open bug)

Details

(Whiteboard: [workaround in comment 11, 19])

Attachments

(1 file, 3 obsolete files)

proposed fix
1.01 KB, patch
Bienvenu
: review+
Bienvenu
: superreview+
Details | Diff | Splinter Review
ENVIRONMENT =========== any STEP ==== 1. add the following to your prefs.js user_pref("mail.strictly_mime.parm_folding", 3); 2. create new message 3. attach file using DBCS filename 4. send the mail DESCRIPTION =========== In RFC2231, the charset used to filename parameter is encoding name of filename. But Mozilla uses encoding name of attached contents. This test case is HTML file. This HTML is encoded by IOS-8859-1, but filename is Shift_JIS. Message-ID: <3A644162.50404@din.or.jp> Date: Tue, 16 Jan 2001 07:41:06 -0500 From: Makoto Kato <break@din.or.jp> To: Makoto Kato <break@din.or.jp> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; m18) Gecko/20010114 X-Accept-Language: ja, en MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------000307060307040304040508" This is a multi-part message in MIME format. --------------000307060307040304040508 Content-Type: text/html; charset=ISO-8859-1; name*=ISO-8859-1'ja, en'%82%A0%82%A2%82%A4%82%A6%82%A8.html Content-Transfer-Encoding: base64 Content-Disposition: inline; filename*=ISO-8859-1'ja, en'%82%A0%82%A2%82%A4%82%A6%82%A8.html PCFET0NUWVBFIGh0bWwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMDEgVHJhbnNpdGlv bmFsLy9FTiI+DQo8aHRtbD4NCjxoZWFkPg0KICA8bWV0YSBodHRwLWVxdWl2PSJjb250ZW50 LXR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD1JU08tODg1OS0xIj4NCiAgPHRp dGxlPiYjMTIzNTQ7JiMxMjM1NjsmIzEyMzU4OyYjMTIzNjA7JiMxMjM2Mjs8L3RpdGxlPg0K PC9oZWFkPg0KPGJvZHkgYmFja2dyb3VuZD0iW29iamVjdCBXaW5kb3ddIj4NCjxicj4NCjwv Ym9keT4NCjwvaHRtbD4NCg==
Can you reproduce this with the latest nightly build and then report back here? Thanks!
I tested latest build and my private build from currently CVS source.
Attached patch fix code at 2001/01/27 (obsolete) — — Splinter Review
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: patch, review
please don't use tabs. [actually, you might not be using tabs, i can't tell, it doesn't matter] [and yes I know you didn't write the original code] the modeline is: 1 /* -*- Mode: C++; tab-width: 2; indent-tabs-mode: nil; c-basic-offset: 2 -*- so please use 2 spaces for each level of indentation. + char *rfc2231Parm = RFC2231ParmFolding("name", fileCharset, + nsnull, real_name); should be fine. [and similar] however, i suspect .Get() might be useful. cc jag for comment.
accepting.
Status: NEW → ASSIGNED
Something weird is going on with the Content-Disposition. I've just attached a .zip file and Mozilla (20010316) still generated "Content-Disposition: inline" Content-Type: application/x-zip-compressed; name="HomeSite_4.5.1.zip" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="HomeSite_4.5.1.zip"
ping. String land has probably changed since this patch was made, how's this going?
*** Bug 57069 has been marked as a duplicate of this bug. ***
Changing summary, fixing keywords. See also duplicate bug 57069 for another example. Can someone check on this? I don't run Mail & News...
Keywords: patch, review
Summary: Mozilla may generate incorrent parameter in Content-Disposition header → Some attachments get Content-Disposition: inline (incorrect)
With build 2001-09-04, I still see Content Disposition as inline for attached .zip and .js files as mentioned in the dup bug 57069 and later on in this bug. Note: I see this when sending and receiving these files using 4.7 too. I'm not sure how to test the original scenario in this bug and I don't see that it was resolved as fixed, so this is still a problem.
Target Milestone: --- → mozilla1.0
Unless you set magic pref 'mail.content_disposition_type', all attachments except application/octet-stream, text/x-vcard and application/directory will get Content-Disposition: inline. (See nsMsgCompUtils.cpp, mime_generate_attachment_headers(), near line 982) Hey, guys, does all that magic preferences documented somewhere except your heads? ;-) As for this bug, we may add simple structure, say struct InlineDispositions { char *content_type; short isInline; } And then just initialize it in nsMimeTypes.h: struct InlineDispositions dispositions[] = .... , so choosing disposition will be as simple as dispositions[content-type] ? "inline" : "attachment" (of course, one must use |#define|-s for content-type to be safe)
Target Milestone: mozilla1.0 → Future
QA Contact: esther → trix
I've encountered the same problem with images on PC/M$W2k/mozilla 0.9.7. I've image generated with php : http://host/img.php with Header Content-Disposition: attachment; filename='img-2.png' and choosing 'Save Image ( img.php )' propmts to assumed local filename as "filename='img-2.png'" ( literally ).
*** Bug 142565 has been marked as a duplicate of this bug. ***
So... why are we sending _any_ attachments as content-disposition:inline? Much less anything that does not have a text/* type?? If we really want to make sure text/html and text/plain go inline instead of as attachments, we should reverse our check and attach everything as "attachment" except those two types or something.... Raising severity since this makes some mail clients very unhappy...
Severity: normal → major
Target Milestone: Future → mozilla1.1alpha
*** Bug 143208 has been marked as a duplicate of this bug. ***
I don't think we should automatically inline text attachments. I'm trying to send a text attachment for automatic processing, and the inlining of the attachment is breaking the processor. I'd like for there to be some way to guarantee that an attachment is not inlined in a message.
see bug 66915 "UI for changing content-disposition of outgoing attachments"
mscott, perhaps you could look at this? Some people have been complaining about this bug.
Note that fixing this bug will make bug 66915 obsolete (a better default makes that UI unnecessary). For now, as suggested above, a reasonable workaround is to set mail.content_disposition_type=1. That will (apparently) force Content-Disposition: attachment; and that makes some clients (e.g., Hotmail) much happier.
(In reply to comment #16) > I don't think we should automatically inline text attachments. Me either. If I try to send a Macromedia Contribute connection key (a simple xml file) to someone who uses Eudora (most of my organization) it gets displayed inline and is can't be used. The Content-Type is text/xml and the file has a .stc extension, which is registered to Contribute. Under normal circumstnaces the user needs to be able to save the .stc file to disk and then double click it to launch Contribute and automatically access their website. I would think that "attachment" would be the best default. Whatever heuristics are used to determine if inline should be used instead should take things like .rtf and .stc files into consideration as well. Bug#: 249049 seems to be a similar bug for the Thunderbird branch. N.B. Setting the preference in prefs.js works, for me as well, but it would be nice if this were the default setting.
*** Bug 249049 has been marked as a duplicate of this bug. ***
*** Bug 244544 has been marked as a duplicate of this bug. ***
Please also refer to various discussions at http://forums.mozillazine.org/viewtopic.php?p=536030 and http://forums.mozillazine.org/viewtopic.php?t=78111 advocating sending attachments as "attachments" by default
*** Bug 258449 has been marked as a duplicate of this bug. ***
*** Bug 128735 has been marked as a duplicate of this bug. ***
Hi, I hope this is the right bug to report to. When I send .cfr attachments they are send as text/plain and they shouldn't be. Attachments are not OK even if I send it to myself. I am using user_pref("mail.content_disposition_type", 1); user_pref("mail.inline_attachments", false); I also use enigmail extension. This is the mail source: ------------start------------------- Subject: test X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/mixed; boundary="------------060401050306040904080209" X-Trace: ls401.htnet.hr 1098888929 597 195.29.121.127 (Wed, 27 Oct 2004 16:55:29 +0200) X-UIDL: ;(G"!PEO"!Pf1"!&"l"! This is a multi-part message in MIME format. --------------060401050306040904080209 Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit tekst --------------060401050306040904080209 Content-Type: text/plain; name="Config07-JABA-Final.cfr" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="Config07-JABA-Final.cfr" 003120041027ECMPWR 50108 041020EM7040 23 = HRhr = ---------------end------------ If I use my webmail access to my mail, those attachments a send OK. This is the source of the e-mail: ------------start--------------- Content-Type: multipart/mixed; boundary="MailMan_Boundary" X-Trace: ls401.htnet.hr 1098881996 597 195.29.150.76 (Wed, 27 Oct 2004 14:59:56 +0200) X-UIDL: Fl["!]T]!!M2K!!4~~"! Status: RO This is a multi-part message in MIME format. --MailMan_Boundary Content-Type: text/plain This one should work. --MailMan_Boundary Content-Type: application/octet-stream; name="Config07-JABA-Final.cfr" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Config07-JABA-Final.cfr" MDAzMTIwMDQxMDI3RUNNUFdSICA1MDEwOCAwNDEwMjBFTTcwNDAgMjMgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ----------end--------- As you can see my webmail is using base64 encoding and the attachments are OK.
(In reply to comment #26) > Content-Disposition: attachment; Due to your settings, Content-Disposition is already correct, so this is not this bug. If your file contains CR and LF, these are probably converted to CRLF (bug 161806). A long file without CR or LF may be damaged due to bug 237118. See bug 237118 comment 6 for a workaround for both issues.
Whiteboard: [workaround in comment 11]
*** Bug 269660 has been marked as a duplicate of this bug. ***
Product: MailNews → Core
*** Bug 272329 has been marked as a duplicate of this bug. ***
Summary: Some attachments get Content-Disposition: inline (incorrect) → Some attachments (like text/plain) get Content-Disposition: inline (incorrect)
Whiteboard: [workaround in comment 11] → [workaround in comment 11, 19]
I can't believe it, this bug is opened 3 years ago and still not fixed!!! Excerpt from http://forums.mozillazine.org/viewtopic.php?t=78111 I and some other people are *not* talking about the recipients. You should separate the two sides from each other. On the sender side, I should be able to send an attachment as an attachment. It is up to the recipient, and frankly I don't even care about how s/he does it, to render the attachment inline or show as attachment, according to her/his settings. Just for the convenience of some recipients, one shouldn't do this inline. Surely, one can send files inlined, but then the buttons should be called "insert file" not "attach file". Ironically, the entry under "File" menu is called "Attach -> File(s)" and the button on Compose window simply "Attach" whereas the tooltip for the button says "Include an attachment". My common sense says, a file is to be included (inlined) only either if one composes HTML-mail or if one clicks some "Insert" button, but not "Attach". Briefly, the default *should* be "Attachment". That hack is ugly, not well-known and against common sense.
Still an issue In my opinion also, anything dropped to he attachment area should be sent as an attachment And an other manner to send files inline provided, for example to drag and drop in the message window, see 113435
*** Bug 284604 has been marked as a duplicate of this bug. ***
*** Bug 285763 has been marked as a duplicate of this bug. ***
*** Bug 285763 has been marked as a duplicate of this bug. ***
I confirm that adding user_pref("mail.content_disposition_type",1); in user.js in the profile folder allows to force sending text as attachment tested with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050306 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050306 MIME-Version: 1.0 To: undisclosed-recipients:; Subject: essai en unicode Content-Type: multipart/mixed; boundary="------------080406030401010108030706" X-Duke-MailScanner: Found to be clean X-UIDL: Xec"!%m$"!aHg!!ial"! This is a multi-part message in MIME format. --------------080406030401010108030706 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit --------------080406030401010108030706 Content-Type: text/xml; name="web.xml" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="web.xml" <?xml version=3D"1.0" encoding=3D"UTF-8"?> <!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" "http://java.sun.com/dtd/web-app_2_3.dtd"> <web-app>
Flags: blocking-aviary1.1?
>I confirm that adding >user_pref("mail.content_disposition_type",1); in user.js in the profile folder >allows to force sending text as attachment So why, when this was first suggested over 3 years ago, on a bug file that has been open for over 4 years, and on which there has not been a single dissenting comment suggesting that perhaps this shouldn't be the default behaviour, has this *not been fixed yet*? I would have thought that changing the default value of this option would be a five minute change that could be included in CVS within about half an hour of somebody with access sitting down to do it, probably along with a string of other similar flaws. What's going on? Why are these bugs (and ones like bug 35389, bug 54570, bug 52821, bug 61363, bug 120278 and numerous others listed in bug 122274) not being fixed?
This patch makes pref("mail.content_disposition_type", 1); the default.
Attachment #187074 - Flags: review?(bienvenu)
I prefer them to be inline myself...perhaps adding a ui to let the user pick would be the way to go?
Attached patch UI for pref (obsolete) — — Splinter Review
This patch adds UI for the mail.content_disposition_type pref for thunderbird. I'll work up a UI patch for SeaMonkey as well, when this patch is OK'd.
Assignee: ducarroz → baafie
Attachment #187116 - Flags: review?(bienvenu)
Please see comment 11. This bug is about faulty code in nsMsgCompUtils.cpp. The pref is just a workaround. Instead of setting the pref by default, mime_generate_attachment_headers() ought to be fixed. bienvenu, I prefer text attachments inline as well, but it really doesn't matter to the sender, does it? And the recipient's UI will handle text/plain and similar attachments as the recipient sees fit. If this bug is fixed the right way, it should get zero UI exposure. In any case, the UI is in bug 66915.
(In reply to comment #40) > Please see comment 11. This bug is about faulty code in nsMsgCompUtils.cpp. The > pref is just a workaround. Instead of setting the pref by default, > mime_generate_attachment_headers() ought to be fixed. Sure. But the bug hasn't been fixed for more than 4 years now. I'm not complaining about that, but setting the pref by default would be a workaround for the next 4 years. The situation would be much better than it is now. > If this bug is fixed the right way, it should get zero UI exposure. In any case, > the UI is in bug 66915. I totally agree.
(In reply to comment #40) > bienvenu, I prefer text attachments inline as well, but it really doesn't matter > to the sender, does it? [..] > If this bug is fixed the right way, it should get zero UI exposure. Well, rfc8213 seems to be our point of reference here: > A bodypart should be marked `inline' if it is intended to be displayed > automatically upon display of the message. Inline bodyparts should be > presented in the order in which they occur, subject to the normal semantics > of multipart messages. So if we want to follow spec (as you so elegantly put it, to fix it the "right" way), we should give users a choice. Whether or not recipients ignore the Content-Disposition header field should be of little interest to us. In any case, the default should be `attachment', in my opinion.
Comment on attachment 187116 [details] [diff] [review] UI for pref I'm not comfortably having UI for something like this. This is not something an end user like my grand mother is going to understand or need to change. Powers uses can use about:config to change it. Nor am I convinced that we should be changing our default value for this.
Attachment #187116 - Flags: superreview-
(In reply to comment #43) > (From update of attachment 187116 [details] [diff] [review] [edit]) > I'm not comfortably having UI for something like this. This is not something an > end user like my grand mother is going to understand or need to change. That's true. > Nor am I convinced that we should be changing our default value for this. But the current default leads to a typical grandma problem: rtf-Files are shown in the emails in all their beauty with control characters and everything.
Random suggestion: we could add an "Insert [..] file.." button into the right-click context menu of the email composer window (or elsewhere in that window). The normal attachments could then be sent with the `Content-Disposition: attachment' header and the inserted files could be sent as inline. That way, users a) would be able to control the inline-ness without being exposed to the details, b) people could more easily control the order of attachments/text and c) people using other clients would stop complaining.
(In reply to comment #0) > ENVIRONMENT > =========== > any > > STEP > ==== > 1. add the following to your prefs.js > > user_pref("mail.strictly_mime.parm_folding", 3); > > 2. create new message > 3. attach file using DBCS filename > 4. send the mail > > DESCRIPTION > =========== > In RFC2231, the charset used to filename parameter is encoding name of > filename. But Mozilla uses encoding name of attached contents. > > This test case is HTML file. This HTML is encoded by IOS-8859-1, but filename > is Shift_JIS. > > > Message-ID: <3A644162.50404@din.or.jp> > Date: Tue, 16 Jan 2001 07:41:06 -0500 > From: Makoto Kato <break@din.or.jp> > To: Makoto Kato <break@din.or.jp> > User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; m18) Gecko/20010114 > X-Accept-Language: ja, en > MIME-Version: 1.0 > Content-Type: multipart/mixed; > boundary="------------000307060307040304040508" > > This is a multi-part message in MIME format. > --------------000307060307040304040508 > Content-Type: text/html; charset=ISO-8859-1; > name*=ISO-8859-1'ja, en'%82%A0%82%A2%82%A4%82%A6%82%A8.html > Content-Transfer-Encoding: base64 > Content-Disposition: inline; > filename*=ISO-8859-1'ja, en'%82%A0%82%A2%82%A4%82%A6%82%A8.html > > PCFET0NUWVBFIGh0bWwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMDEgVHJhbnNpdGlv > bmFsLy9FTiI+DQo8aHRtbD4NCjxoZWFkPg0KICA8bWV0YSBodHRwLWVxdWl2PSJjb250ZW50 > LXR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD1JU08tODg1OS0xIj4NCiAgPHRp > dGxlPiYjMTIzNTQ7JiMxMjM1NjsmIzEyMzU4OyYjMTIzNjA7JiMxMjM2Mjs8L3RpdGxlPg0K > PC9oZWFkPg0KPGJvZHkgYmFja2dyb3VuZD0iW29iamVjdCBXaW5kb3ddIj4NCjxicj4NCjwv > Ym9keT4NCjwvaHRtbD4NCg== The reason the default behavior is an issue, is that it causes attachments to go inline when sending to 90% of the mail clients currently in use. Unfortunately, that includes the most common clients like Outlook. When your typical user attaches a text file, he expects it to be sent as an attachment, not inline. Inserting a file would be expected to perform that function, not attaching a file. The result is a major headache since the default behavior renders all attachments worthless to the end recipient. My guess is most users, not just power users, will find that in order to communicate to anyone else, they have to change the default. That would suggest the default is not correct.
(In reply to comment #43) > I'm not comfortably having UI for something like this. This is not something an > end user like my grand mother is going to understand or need to change. Powers > uses can use about:config to change it. > > Nor am I convinced that we should be changing our default value for this. I think the issue is definitely not about having a GUI for this setting; it's the default setting what matters. I agree with other people, "attach file" should, as it says, simply "attach", and there should be a separate button called "insert a file at the cursor" or alike. OTOH if someone desperately wants to insert a file in the middle of an email, IMO s/he should compose HTML-mails in the first place and there s/he can insert as many files s/he wishes.
I want to reiterate what many are saying and what I have been trying to say for years, here and on mozillazine forums: this bug prevents me to recommend tb to my colleagues. In the scientific world people frequently send latex file to each other, and don't want them to show up inline (they are unreadable anyway, with formatting and all, not to mention that these are usually big text files that people want to save and compile). I don't think there should be a UI Change either. Attachments should be attached, period. If you want to keep the current behavior, than please call attachments something else.
Attachment #187116 - Flags: review?(bienvenu)
The severity of this attachment issue is not "major", it is a "blocker". Try this: "Write" new email. "Attach" a .CSV (comma separated values) file. "Save" email. Double mouse click on the file name in attachments pane -- spreadsheet program of your choice opens, all the data is there in correct columns. Close the "Compose" window. [Oh, here's a naming inconsistency.] Now click on "Drafts" folder. Select the just-composed [just-written?] email. The nice .CSV file is now text. Double mouse click on the file name in the attachments window -- spreadsheet program of your choice again opens, all the data is jammed up into the first column. I have the following three settings in my user.js file, which have been copied into prefs.js: user_pref("mail.content_disposition_type", 1); user_pref("mail.file_attach_binary", true); user_pref("mail.inline_attachments", false); For a four-year old bug, this is a show-stopper.
Flags: blocking-aviary1.1? → blocking-aviary1.1-
Summary: Some attachments (like text/plain) get Content-Disposition: inline (incorrect) → Some attachments (like text/plain, text/html) get Content-Disposition: inline (incorrect)
Target Milestone: mozilla1.1alpha → ---
*** Bug 307687 has been marked as a duplicate of this bug. ***
Flags: blocking-thunderbird2?
*** Bug 329890 has been marked as a duplicate of this bug. ***
*** Bug 328266 has been marked as a duplicate of this bug. ***
*** Bug 328266 has been marked as a duplicate of this bug. ***
*** Bug 339355 has been marked as a duplicate of this bug. ***
I'm not working on this.
Assignee: b.jacques → nobody
Status: ASSIGNED → NEW
QA Contact: stephend → mime
*** Bug 351399 has been marked as a duplicate of this bug. ***
we're not going to change the default attachment type.
Flags: blocking-thunderbird2? → blocking-thunderbird2-
There is no such thing as an 'attachment type'. There are two 'Content-Disposition' standard values for MIME parts: 'attachment' and 'inline'. thunderbird wrongly assigns 'inline' to a part that has been explicitely required by the user to be 'attached', which is a bug.
(In reply to comment #57) > we're not going to change the default attachment type. > I can't belive this. This damm old bug will still remain in Version 2? It was a bug and it will always be a bug! So come on and finally fix it, please!
(In reply to comment #59) > (In reply to comment #57) > > we're not going to change the default attachment type. > > I can't belive this. This damm old bug will still remain in Version 2? > It was a bug and it will always be a bug! > So come on and finally fix it, please! Did you somehow miss the information in the status whiteboard at the top of this bug that reads "workaround in comment 11, 19"? It's a simple thing to get the behavior you want.
Status: NEW → ASSIGNED
(In reply to comment #60) > Did you somehow miss the information in the status whiteboard at the top of > this bug that reads "workaround in comment 11, 19"? It's a simple thing to get > the behavior you want. It's not about me. On all my installations this is the first thing which I do. But I'm thinking about all the users out there which don't even known about it. They just see that something is not working as expected and and it's may a reason for them to switch to different program. It's a very annoying bug! May someone can explain why it will not be fixed or at least why the patch of comment #37 isn't applied? This would be great.
Workarounds are fine for people who know the bug. But if you want to attract a wider audience, you need to avoid having bugs that people need to work around. A lot of people are going to experience this bug, and many of them won't know why what they're doing is going wrong. How is a novice user supposed to work out how to work around it?
> > > we're not going to change the default attachment type. > > > > I can't belive this. This damm old bug will still remain in Version 2? > > It was a bug and it will always be a bug! > > So come on and finally fix it, please! > > Did you somehow miss the information in the status whiteboard at the top of > this bug that reads "workaround in comment 11, 19"? It's a simple thing to get > the behavior you want. > It's simple once you actually find the "workaround". (Arthur Dent should've known his house was going to be bulldozed, too.) I've had TB 6 months now, and only just found this solution. (Call it a sign of my poor Google skills, but the point is that not everyone is going to search out this "workaround.") Let me just throw in my opinion, which agrees with some previous posters. (1) This is clearly a bug. (2) This is a turnoff to people (like academics who mail TeX files) expecting an obvious behavior from TB, but getting another. I also cannot recommend TB to colleagues for this reason. (3) What I find most puzzling is that some people think this shouldn't be changed. People can cut and paste to get inline; why would they expect an attachment not to be attached? Thanks for listening.
Let me add my voice to the others calling for this to be fixed. Until there is an easy, scalable, and low-resource intensive way to distribute configs to all my users to make the browser work the way it is supposed to (with minimum fuss to the largest number of potential recipients) - and that is assuming I've combed through Bugzilla to find all the small work arounds that make it work well - it needs to be fixed in the install. Installs I can do realatively simply, its all the tweaking after the fact that eats up my department's time. I've always thought that anything that shows up in the attachment box of the compose window (either through "attach file" or drag to the box) should show up as an attachment, and anything dragged/copied/inserted into the body should be inline; short of that functionality being added, can we just fix 80% of the problem now and do the "right" fix when someone has the time to do it (this one is already done short of the approval, even if you don't add in the UI).
Can someone please respond to this list and explain why this bug is such a difficult one to fix?
Can someone please respond to this list and explain why this bug is such a difficult one to fix? It's been six years since this bug was identified and still nothing has been done to fix it? That's unheard of.
Unheard of? Not really, bug 17796 is over seven years old, and has had a working patch waiting for review for the best part of four years, but has yet to be resolved. Nobody cares about fixing it. Bug 57882 is older than this one yet still not fixed, and that's a fairly simple, easily reproducible layout bug that probably shows up for most users at some time or another. Nobody cares about fixing it. Bug 35389 - nobody cares. Bug 54570 -- intensely annoying for those of us who subscribe to mailing lists in digest format, but nobody cares enough to apply the 5-year-old patch. Bug 61363 is a priority 1 critical dataloss bug that has been unfixed for over six years; it was being actively worked on in March 02, but then everything went suddenly quiet, and the people working on it haven't been heard from since... This bug can be fixed with a single line code change that is obvious to anyone who reads the description of it and the working workaround that has been presented: make the workaround setting the default. But nobody cares enough to spend the time fixing it, because mozilla.org's beaurocracy makes committing any change to the codebase too problematic in cases of trivial problems like this one.
Bureaucracy? Certainly not! :) It's just a matter of different opinions on what the correct setting should be.
Perhaps somebody who believes the default shouldn't be changed could explain why this should be the case, then, if people really do believe that. Because there are plenty of arguments above for changing it, and not a single one for keeping it. Other than "we're not going to change the default attachment type," and "did you not see the workaround?" As for the suggestion that the bug is the one described in comment 11, that doesn't sound right at all to me. Comment 11 describes code changes that are necessary to support choosing whether or not to put a specific "attachment" inline. The bug is that no attachments should inline, because inline and attachment are two completely different things.
This is a bug, not "a matter of different opinions on what the correct setting should be." <a href="show_bug.cgi?id=65794#c11">Comment 11</a> has been referred to as a workaround, but code changes are not workarounds, and I don't understand what Comment 11 is telling me to do anyway. Regardless what the default is, there should be a simple way to change this preference, like another Boolean option for the "mail.content_disposition_type" The status of this bug is pathetic.
Thanks, guys, this **** gave me a lot of troubles today. Why this bloody thunderbird thinks that it knows better than me what I want to do. I put it as attachment and I have never meant to be it inside the message body.
Aleksey, have you tried setting the pref described in comments 11 and 19? set mail.content_disposition_type to 1 and you will actually be telling Thunderbird what you want to do.
Yes, David. Unfortunately, I tend to read bugzilla only after I have encountered a bug. Not sure whether it is normal or not. In my opinion, the default behavior should not cause problem. "inline" DO cause problems, "attachment" DOES NOT. If people care so much about this "inline" rudiment it might make sense to add an option to "Attach" sub-menu. That's that.
I am now playing with Thunderbird 2.0, released yesterday, and it seems that bug is still present (Thunderbird sent my ZIP file as an inline file...). After looking on some forums I found that setting "mail.content_disposition_type" to 1 would resolve that bug, and it did. It seems that a lot of people are impacted by that so that's why I add this 74th comment to try to reach that 6 years old bug closure: [WHY] -> The default value of "mail.content_disposition_type" is 0, which makes Thunderbird to set attachments files as "inline" or "attachment" automatically, depending on the file type. -> The problem is that the choices made by Thunderbird are sometimes wrong and there is no possibility for the user to manage it. [SOLUTIONS PROPOSAL] 1) Make "mail.content_disposition_type" default value to 1 or (cf https://bugzilla.mozilla.org/show_bug.cgi?id=65794#c57) 1bis) Make a list of all kind of files and discuss about the corresponding "inline" or "attachment" default behavior for each. 2) Add a functionality that would allow the user to manage the "inline" or "attachment" choice for each file type. [SOLUTIONS IMPLEMENTATION] 1) Set "mail.content_disposition_type" default value to 1 1bis) For all "Content-Type" dealing with text and images, "Content-Disposition" can be "inline", for others it should be "attachment" 2)In Tools/Options/Composition/General, above "Forward messages", add an "Attach files as" setting with those possibilities: "Auto"/"Attachment"/"Inline". Selecting "Auto" enables a button "Manage" on the same line, on the left. Clicking on "Manage" button allow the user to set the "Inline" or "Attachment" behaviour for each file type
Yeah ... jeannich is so right! It would be only a small step for a developer to implement this fix but a very big step for the program. (If the developers needs some time - let's say again six year or something around that - why not just apply the workaround?) May we need more votes? Ok ... guys come on and tell (force) all friends to vote on this bug! May it helps ...
Another reason why getting text and html inline is not useful is that encoding often is different (esp html tend to be utf-8 now), but we use just one encoding for display. (Maybe there's a bug for that to...)
Up! Could this behavior be fixed? Today I've "attached" a word document to an important mail. As I wasn't aware of the default bahavior, the attachement was inlined, so the receiver saw very strange characters and wasn't able to save and read the attachement. I made myself a fool. "He is not even able to send an attachement". Thanks TB!
I also just got bit by this bug. I tried to email a vcard to my iPhone, but it kept arriving as the raw text, which the iPhone didn't recognize as a vcard (you know Steve, he's got this thing about form). 3 man hours later, I finally figured out it was content-disposition that was the culprit. In fact, it bit me earlier in the day in a different way, when I tried to send an xml file with a filename that ends in .swgame; he got it but the xml appeared in the message text, and when he copied it out, it was a bit mangled. I finally had to zip it to get it to work. Bugs where the user interface does something opposite to a reasonable user's expectations are IMHO major bugs. They are frustrating, and cause loss of time and confidence in the application. I would add my voice to the chorus that is suggesting that files dragged into the attachment area get sent as attachments, and files that get dragged into the message area get sent inline, and that furthermore, the first time a user includes an attachment, a popup (with the obligatory "do not show this message again" checkbox) comes up to explain the behavior, perhaps something like: Sending files in email: There are two ways to include a file with your email. If you drag the file into the right side of the address area at the top of the mail, your file will be "attached" to the text of your email, but will not be part of it -- think of it as paperclipping a photo to your letter, or adding a sticky note. This method is best when sending files that your recipient may want to save for later use. If you drag the file into the actual body of the email, it will be "included" as part of your email -- think of this as actually printing the photo as part of the letter, or writing your note directly on the letter. This method gives you more control over how and where your file appears inside the email, but your recipient may not be able to easily extract it. IMNSVHO, this is the best way to educate users about subtle "gotcha" behaviors. I've been using email since 1976, and this was the first I'd heard about the two content-dispositions.
In general, only attachments that can be usefully interpreted and displayed inline should be able to get that disposition. So, if there is no suitable method to display it inline (which could be defined by some inlinable content type list), it should go out with an "attachment" disposition regardless of the mail.content_disposition_type preference. I wouldn't mind retaining its default "inline" as long as non-inlinable attachments (e.g., PDF or Word files) are sent with an "attachment" disposition. (In reply to comment #64 and comment #78) > I've always thought that anything that shows up in the attachment box of > the compose window (...) should show up as an attachment, and anything > dragged/copied/inserted into the body should be inline; Some attachments can be considered a substantial part of the message, and therefore should be included when displayed and replied to, whereas others are "true" attachments in nature, even if their MIME types are identical. Thus, it sounds like a good idea to make this decision individually selectable for an attachment, rather than basing it on a global pref alone. Keep in mind though that the drag-into-message-body semantics is already taken by a third type of attachment: Adding it as part of the HTML message within a "multipart/related" rather than "multipart/mixed" top content type. This works well for images, but is rather broken for text (bug 113435). Expanding on your suggestion: (a) Drag-and-drop of text/plain, text/html, and message/rfc822 attachments into the message body will cause them to be attached with a disposition of "inline" (solving bug 113435 in the process); (b) drag-and-drop of image/* attachments into the message body (1) attaches them as "inline" if the message is composed in plain-text mode, or (2) embeds them into the message for HTML mode; (c) any files of those MIME types dragged into the attachment area attaches them with a disposition according to mail.content_disposition_type (which could be "1" by default then); (d) any other file types (which likely cannot be displayed inline) are attached with "attachment" disposition.
Hi, some users at the office have related problems sending attachments (using the Attach button) that appear as "inline" to the recipients, even when mail.content_disposition_type is set to 1. We've just realized that this occurs when there are no actions associated to the file type in Preferences/Attachments dialog. In this case the generated content-type for a DOC word document (for instance) is like "text/richtext", instead of "application/msword" or something. It seems to me as a weird, unexpected behaviour, and it seems that it's barely related to this bug too, but it's true that once the association is set everything becomes ok.
Flags: blocking-thunderbird3?
I am seeing too many MIME content errors being generated by mailnews core, where the sending platform is Windows. Part of the cause originates in the Windows registry where Windows NT makes use of Namespaces in place of MIME when associating file types. Tbird is looking at the Windows registry and using Namespace to generate Content Type: that are invalid MIME. The result is frequent "One-Off" content types that defy setting proper content handling for received messages, mail or news. This is a case where the long dead NC 4.x had a MIME lookup table drawn from a file built up through it's Preferences system that facilitated matching a valid MIME to the files being attached. We were able to edit the file through the Preferences module to locally add new MIME associations in anticipation of use with recently installed applications. While the MIME Edit extension might help in some ways, it does not resolve the need for a solid solution. With the move to more use of sqlite, would not a sqlite db offer a fast lookup method to implement a standard data base of common MIME to file type parings?
Blocks: 442448
Product: Core → MailNews Core
This is not a blocking bug, but I've marked it wanted, p1, to at least try this out.
Flags: wanted-thunderbird3+
Flags: blocking-thunderbird3?
Flags: blocking-thunderbird3-
Priority: -- → P1
Target Milestone: --- → Thunderbird 3.0b2
Attached patch proposed fix — — Splinter Review
Inspired by the last comment :) Just to be clear: this doesn't change how text etc is displayed in moz mail. Just what we send out.
Assignee: nobody → mkmelin+mozilla
Attachment #23636 - Attachment is obsolete: true
Attachment #187074 - Attachment is obsolete: true
Attachment #187116 - Attachment is obsolete: true
Attachment #335210 - Flags: superreview?(bienvenu)
Attachment #335210 - Flags: review?(bienvenu)
Attachment #187074 - Flags: review?(bienvenu)
Comment on attachment 335210 [details] [diff] [review] proposed fix sure, let's try it.
Attachment #335210 - Flags: superreview?(bienvenu)
Attachment #335210 - Flags: superreview+
Attachment #335210 - Flags: review?(bienvenu)
Attachment #335210 - Flags: review+
changeset: 188:e76298201107 http://hg.mozilla.org/comm-central/index.cgi/rev/e76298201107 ->FIXED
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Target Milestone: Thunderbird 3.0b2 → Thunderbird 3.0b1
I filed my comment #79 as an enhancement request in bug 452092 to summarize the additional ideas for MIME-type based or interaction-determined content disposition of attachments for sending, since this bug has now been resolved with a minimal solution. Those additional ideas should still be considered. Please feel free to add comments to the spin-off bug for any further ideas.
Depends on: 462266
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: