Closed Bug 534605 Opened 16 years ago Closed 14 years ago

messages attached have no charset specified

Categories

(Thunderbird :: Message Compose Window, defect)

x86
Linux
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: pch, Unassigned)

Details

(Whiteboard: [closeme 2012-03-25])

User-Agent: Mozilla/5.0 (X11; U; Linux i686; de; rv:1.9.1.6) Gecko/20091201 Firefox/3.5.6 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; de; rv:1.9.1.5) Gecko/20091121 Thunderbird/3.0 Dragging a message from a list pane to the compositor window creates an attachment of that message as "text/html". These attachments do not specify the charset in which they are encoded - it is the same as the message, yet thunderbird displays those html attachments as if they were in iso-8859-1. Reproducible: Always Steps to Reproduce: 1. start message composition 2. drag another message to the attachments area 3. save draft 4. look at the drafts source Actual Results: attached message has " Content-Type: text/html; name="Nachrichtenteil als Anhang" " and no charset specified. Expected Results: attached message should have "Content-Type: text/html; charset=XX-YY; name=..." where charset is the one from the NEW message, as thunderbird recodes the original message in the charset of that one. I am composing messages in the utf-8 charset. Attachments created in the way described above are shown with charset latin-1 even though the newly composed message displays fine. Nothing will change, when I actually send the message and look at it in the Sent folder.
(In reply to comment #0) > 2. drag another message to the attachments area That doesn't work for me (on a mac). Where do you get your message from, the message list ?
Here I have drag one of my message to desktop, I compose a new (empty) message and I have attached (drag and drop from desktop) the *.eml file. In message source I see: Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit ...but I have problem when double click on this attachment: TB don't open it but prompt me a "Launch application" window ("this link..."): it is strange
(In reply to comment #1) I did drag from the inbox or the sent messages list (In reply to comment #2) Attaching .eml works fine here too: I saved an utf-8 encoded message to file and dragged it from the filemanager to the compose window, saved a draft and voilà, the message displays fine, because unlike with dragging from a messagepane list inside thunderbird all the original headers are preserved. (Your problem might be better addressed in a different bugzilla report.) Then I tried attaching a plain text document. File contents are displayed as iso-8859-1 when looked at as a draft or in the sent folder and inbox, when sent to myself. There is no charset added. I wonder, why this never appeared to me before, is this a regression in TB3? Some mail user agents allow setting a content-type and charset for attachments, but this I believe involves the typical thunderbird user too much. Webbrowsers, and texteditors too, use heuristics to determine charset, if none is specified. Should that happen when attaching a plaintext or html file or when displaying? Is this bugreport actually a wishlist-item?
(In reply to comment #3) > (In reply to comment #1) > I did drag from the inbox or the sent messages list I can't do that. Do you have an extension to do that ? > > I wonder, why this never appeared to me before, is this a regression in TB3? Maybe - that's what we are trying to figure out. > Some mail user agents allow setting a content-type and charset for attachments, > but this I believe involves the typical thunderbird user too much. > > Webbrowsers, and texteditors too, use heuristics to determine charset, if none > is specified. Should that happen when attaching a plaintext or html file or > when displaying? Is this bugreport actually a wishlist-item? For that last point it is a wish list you could create a new bug - or search for an existing bug already requesting the same thing. For now my issue is that I can't drag a message to the composition window in thunderbird - so your issue might be in an extension. Can you run Thunderbird in -safe-mode (http://kb.mozillazine.org/Safe_mode) and try to follow your steps ?
(In reply to comment #4) > (In reply to comment #3) > > (In reply to comment #1) > > I did drag from the inbox or the sent messages list > > I can't do that. Do you have an extension to do that ? It is bug #227305 (All OS related: here work fine)
(In reply to comment #3) You have to drag to the recipients pane, not the message body of the composition window, did you do that? Only addon here is GlodaQuilla. In safe-mode thunderbird3 of course started indexing everything - please vote for bug 518584 - but I can still drag and drop messages from lists. Before submitting this issue I did the following search https://bugzilla.mozilla.org/buglist.cgi?quicksearch=attachment+charset the first items title does not seem to be related but the contents may Its bug 477442 - comment 2 seems to indicate a regression: "The problem here is that we no longer..." I crosschecked with debian icedove, which is based on TB2: messages from a list inside TB2 are attached as Content-Type: message/rfc822; name="Nachricht als Anhang" with all/most of the original headers, so it displays OK. while in TB 3 such messages are attached as Content-Type: text/html; name="Nachrichtenteil als Anhang" with none of the original headers, so it displays wrongly. (The base64 encoded text of that attachment is some html written by thunderbird3.) Translation of localized strings above: Nachricht = message, Nachrichtenteil = part of message. als Anhang = as attachment. Plain text attachments do not get a charset in TB2 either. There are some very old bugs on the subject returned from above search.
(In reply to comment #0) > Gecko/20091121 Thunderbird/3.0 > Steps to Reproduce: >(snip) > 2. drag another message to the attachments area > Actual Results: > attached message has " > Content-Type: text/html; name="Nachrichtenteil als Anhang" > " and no charset specified. > Expected Results: > attached message should have "Content-Type: text/html; charset=XX-YY; name=..." "Attached message by Drag&Drop" was sent with message/rfc822 by Mozilla/Mozilla App Suite/Tb1/Tb2/Sm1/Sm2, and was/is usually sent with message/rfc822 by other many mailers, and it has been corrupted by Tb3 - Tb3 sends Drag&Drop'ed mail(s) with text/html(bug 532779). Please focus on charset of usual HTML or text file attachment only. AFAIR, enhancement for charset of text attachment is already requsted.
(In reply to comment #7) Hello WADA, I see you are pretty active on the bugzilla. Please excuse me messing up multiple subjects while researching this issue: it started out with me noticing that in attached messages special chars are messed up. And the missing charset in the attachments header came first as a candidate for this misbehaviour. Comparing with TB2 I realized, that the *regression* actually stems from the fact, that the content-type of the attachment has changed between versions. There may be two causes for this: during the drag the message list (drag source) no longer advertises message/rfc822 or the message compose window (drag target) no longer prefers or accepts message/rfc822 content. The message/rfc822 content-type is widely supported - except for maybe privacy concerns - there is no reason to use customly generated text/html with messages, even plaintext ones, when they are attached by dragging them from a message list. The bug you reference is also a little convoluted. I was all for closing this bug and opening a fresh one, that is on the subject above solely. What do you think? peter
can you reproduce this using a current version of thunderbird? if you are unable to reproduce, please close by setting stats to resolved, and resolution to WORKSFORME or another appropriate setting. If you are able to reproduce, add new details, and a testcase if one does not already exist in the bug report.
Whiteboard: [closeme 2012-03-25]
Now at TB 10.0.2, dragging messages from some list to a composers attachment area works for me. The behaviour seems to have reverted to the same as has been with TB 2: no more do they appear as text/html as in TB 3 but instead as message/rfc822 with all the original headers in place.
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.