Closed Bug 532779 Opened 15 years ago Closed 15 years ago

Unable to open Attached Message Part (this bug:Tb3 generates text/html part instead of message/rfc822 for attached mail, bug 533462:Unable to open text attachment by external program)

Categories

(Thunderbird :: General, defect)

Product:
Thunderbird
Component:
General
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(thunderbird3.0 .1-fixed)

Status:
VERIFIED FIXED
Milestone:
Thunderbird 3.1a1
Tracking Flags:
Tracking Status
thunderbird3.0 --- .1-fixed

People

(Reporter: AntoineW, Assigned: philbaseless-firefox)

References

Details

Attachments

(2 files)

OpenAttachment popups
(deleted), image/png
Details
fixes drop target urls ranking
(deleted), patch
mkmelin
: review+
mnyromyr
: review+
standard8
: approval-thunderbird3.0.1+
Details | Diff | Splinter Review
User-Agent: Opera/9.80 (Windows NT 5.1; U; en) Presto/2.2.15 Version/10.10 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.5) Gecko/20091130 Lightning/1.0b1pre Thunderbird/3.0 When dragging an existing message to a new message window, an attachement named Attached Message Part is created. After sending the message and opening that message in the sent message, I can not open that attachement with Thunderbird. I imagine the same problem would arise when receiving such an attachement from someone else. I'm not sure if this should be in General or OS Integration Reproducible: Always Steps to Reproduce: 1. Write a new message 2. Drag an existing message from a local folder (from the main Thunderbird window) to the attachement part of the window 3. Send the message 4. Go to sent messages and open that message 5. Double click on the attachement (Attached Message Part) 6. It asks which program I want to open the attachement with 7. Select either Thunderbird or another app Actual Results: If I select Thunderbird (by navigating to c:\...\Thunderbird.exe) to open the attachement, it creates a new Thunderbird process which exits quickly but recursively opens another Thunderbird process and another and another... I can then no longer interact correctly with the main Thunderbird window because a new Thunderbird window takes the focus a few times every seconds (but exits before being displayed). Thunderbird exits cleanly if I close all opened windows. If I choose another app (say Notepad2), the other app displays an error message like this one : c:\Program Files\Mozilla Thunderbird\mailbox:///D|/Antoine/mail/local/Sent?number=405603504&part=1.2&filename=Attached%20Message%20Part&type=text/html&filename=Attached%20Message%20Part This is probably a path that can only be understood inside of Thunderbird. Expected Results: Displays the message contained in the attachement This is using TB3 RC2
Version: unspecified → 3.0
Checked with next build. > Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.5) Gecko/20091129 Shredder/3.0.1pre Compose a text mail, attach a mail by Drag&Drop of mail in local mail folder, then "Send Later". Tb 3 generated next header for the attached mail part. > --------------010901020302090202050607 > Content-Type: text/html; > name="Attached Message Part" > Content-Transfer-Encoding: base64 > Content-Disposition: attachment; > filename="Attached Message Part" Confirming. Antoine W. Campagna,, can you produce problem with newest build? > http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-comm-1.9.1/ > http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-comm-1.9.1-l10n/
Severity: normal → major
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking-thunderbird3?
Summary: Unable to open Attached Message Part → Unable to open Attached Message Part (Tb3 generates text/html part instead of message/rfc822 for attached mail)
Data obtained by "Save" of the attachment. (attached mail is simple text mail) > <html> > <head> > <title>Re: 1KB-000004</title> > <link rel="important stylesheet" href="chrome://messagebody/skin/messageBody.css"> > </head> > <body> > <table border=0 cellspacing=0 cellpadding=0 width="100%" class="header-part1"><tr><td><div class="headerdisplayname" style="display:inline;">Subject: </div>Re: 1KB-000004</td></tr><tr><td><div class="headerdisplayname" style="display:inline;">From: </div>&lt;T-000004-M-000001@f.f.f&gt;</td></tr><tr><td><div class="headerdisplayname" style="display:inline;">Date: </div>Sat, Jan 01 00:00:00 1970 +0000</td></tr></table><table border=0 cellspacing=0 cellpadding=0 width="100%" class="header-part2"><tr><td><div class="headerdisplayname" style="display:inline;">To: </div>&lt;M-000001-T-000004@t.t.t&gt;</td></tr></table><br> > <div class="moz-text-plain" wrap=true graphical-quote=true style="font-family: -moz-fixed; font-size: 13px;" lang="x-western"><pre wrap> > Mail line number = 00000001 >(snip) > Mail line number = 00000018 > > </pre></div></body> > </html>
Did this happen with Thunderbird 2? If not, this is a regression, and it would be interesting to know the results of a binary search on nightly builds to figure out how it got introduced. I think there are multiple possible bugs here: a) Tb is generating text/html rather than message/rfc822 when attaching. bienvenu, is there any chance that this is intentional? Assuming that this is a bug, how important it is would depend heavily on what other popular MUAs do with text/html attachments. b) It may make sense for Thunderbird to handle (or offer to handle) text/html attachments internally (either inline or in a tab) when clicked on. Having some idea of what clients generate such messages in what sorts of situations would presumably make it easier to figure out the best UX here and to understand how important it is to change the current behavior, if at all. c) The infinite loop goofiness is clearly just a bug, but triggering it requires what sounds like a pretty unusual set of actions, so this part definitely isn't a blocker. I don't think we'd block on any of these bugs at this late date. More information of the sorts mentioned above would be helpful in understanding whether we need to get this on the 3.0.x branch and, if so, how quickly...
Flags: blocking-thunderbird3? → blocking-thunderbird3-
(In reply to comment #3) > > a) Tb is generating text/html rather than message/rfc822 when attaching. > bienvenu, is there any chance that this is intentional? No, I believe it's an accident, and I'd bet it has to do with the drag drop handling from the thread pane, and/or something Windows is doing. I don't think 2.0 supported drag drop from the thread pane to the compose window.
Path like next in comment #0 was observed for any text attachment in an old mail, when I asked to open by notepad.exe or sakura editor. > c:\...\Thunderbird\mailbox:///D|/.../Sent?number=405603504&part=1.3&filename=Attached%20Message%20Part&type=text/plain&filename=Attached%20Message%20Part (A) text/plain > --------------020806020907080009020502 > Content-Type: text/plain; name="Attached Message Part" > Content-Transfer-Encoding: base64 > Content-Disposition: inline; filename="Attached Message Part" (B) text/html --------------080906040105060304020607 Content-Type: text/html; charset=ISO-8859-1; name="test-2.html" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="test-2.html" (C) text/plain --------------080906040105060304020607 Content-Type: text/plain; name="imap-log-2.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="imap-log-2.txt" When (B) was opened by Firefox 3.5.2, next message was issued by Fx. > Firefox doesn't know how to open this address, > because the protocol(mailbox) isn't associated with any program. If PDF attachment, Adobe Reader was invoked and PDF was displayed. (D) application/pdf > --------------080809070001070804090708 > Content-Type: application/pdf; name="hpetspec_1.pdf" > Content-Transfer-Encoding: base64 > Content-Disposition: attachment; filename="hpetspec_1.pdf" Document property by Adobe Reader was: > Location: C:\DOCUM~1\wada\LOCALS~1\Temp > File: hpetspec_1-1.pdf There are two independent issues. (1) Temporary file path of text attachment passed to external program becomes long one and/or wrong one in comment #0. (2) text/html part is created for mail attachment by Drog&Drop.
(In reply to comment #4) > I don't think 2.0 supported drag drop from the thread pane to the compose window. Tb 2 generated next part per a mail by Drag&Drop of multiple mails from Tread pane to right of To:/CC: box of Compose window. Attachment box is automatically opened by Drag oeration. > --------------020007010708000803040406 > Content-Type: message/rfc822; name="Attached Message" > Content-Transfer-Encoding: 7bit > Content-Disposition: inline; filename="Attached Message"
Parameter passed to external program when text/plain mail (C) in comment #5 was opened via "Open" menu of Tb. > mailbox:///C|/Documents%20and%20Settings/wada/Application%20Data/Thunderbird/Profiles/wxkq5msh.Gmail-IMAP/Mail/Local%20Folders/Inbox?number=4444260&part=1.3&filename=imap-log-2.txt&type=text/plain&filename=imap-log-2.txt Checked with next Rexx script on MS Win. ("Pull" is prompt to keep MS Win's Command window open) > TEST.REX > /* REXX */ Parse Arg parm; Say parm; Pull Reply; Return;
Summary: Unable to open Attached Message Part (Tb3 generates text/html part instead of message/rfc822 for attached mail) → Unable to open Attached Message Part (Tb3 generates text/html part instead of message/rfc822 for attached mail, Unable to open text attachment by external program)
(In reply to comment #7) > > mailbox:///C|/Documents%20and%20Settings/wada/Application%20Data/Thunderbird/Profiles/wxkq5msh.Gmail-IMAP/Mail/Local%20Folders/Inbox?number=4444260&part=1.3&filename=imap-log-2.txt&type=text/plain&filename=imap-log-2.txt this is data that can be seen with flavor application/x-moz-file-promise-url. I was trying to fix it with Bug 484667 but I don't see that happening with the FF group. We may need to find a different way here and disable it in the meantime. Bug 491239 may be an issue causing the TB acting up when trying to open it, but not sure about that one.
Setting dependency to Bug 484667 and Bug 491239 for ease of tracking.
Dragging a message to a composer attachment bucket and save. With patches for drag and drop mentioned in comment 8 I can drag a text attachment to an external app and shows as html. If I render the html in a browser it looks like it would in the original message if it was to display attachments inline. but opening the attachment I get the same problem as others, the url to the part which an editor doesn't understand. I think d&d of the message should copy a temp file and insert that into the composer attachment pane.
(In reply to comment #10) > With patches for drag and drop mentioned in comment 8 I can drag a text > attachment to an external app and shows as html. If I render the html in a I meant drag an eml attachment. If I drag an actual txt file attachment it will show the text file in the outside editor and indicate it is the temp file that the drag and drop creates. No url problem with d&d just the open attachment command.
Attached image OpenAttachment popups (deleted) —
Attachments open different popups one works for example like pdf's or jpgs or zip files. The other doesn't like txt files, eml files. Wada, can you confirm on latest builds or RC
Bug 533462 has been opened for "Unable to open text attachment by external program" part.
Depends on: 533462
So we should end up with a content-type: message/rfc822 part with a content-dispositon: attachment.
Assignee: nobody → philbaseless-firefox
yes, that's right. Certainly the content-type - the disposition could be inline or attachment.
Attached patch fixes drop target urls ranking (deleted) — — Splinter Review
the drop target should list flavors in order of importance. In this case that would be order of specificity. The the x-moz-url is general and should be on the end. I corrected suite, even though the thread pane only drops the x-moz-message flavor because it doesn't have drag and drop of files to desktop (yet). Hopefully I can correct that now so we don't have to later and because it is right for above reason.
Attachment #417605 - Flags: review?(mkmelin+mozilla)
Status: NEW → ASSIGNED
OS: Windows XP → All
Hardware: x86 → All
Version: 3.0 → Trunk
Workaround (at least on windows XP): drag email you want to attach to the desktop, then drag it onto the mail you're composing - you get the right rfc822 type attachment. Of course, you then have to go back and delete the mail you dropped onto your desktop (or other convenient place).
Flags: blocking-thunderbird3.1?
No longer depends on: 533462
Attachment #417605 - Flags: review?(mkmelin+mozilla) → review+
Comment on attachment 417605 [details] [diff] [review] fixes drop target urls ranking Works nicely, r=mkmelin for the /mail part
Attachment #417605 - Flags: review?(mnyromyr)
Comment on attachment 417605 [details] [diff] [review] fixes drop target urls ranking should consider this for 3.01, after baking on trunk a bit.
Attachment #417605 - Flags: approval-thunderbird3.0.1?
(In reply to comment #22) > (From update of attachment 417605 [details] [diff] [review]) > should consider this for 3.01, after baking on trunk a bit. Can you approve for suite or should I split up the patch so it can get checked in
I definitely can't approve for suite - I think they're going to want this patch too, though.
Comment on attachment 417605 [details] [diff] [review] fixes drop target urls ranking for suite
Attachment #417605 - Flags: review?(mnyromyr) → review?(kairo)
Comment on attachment 417605 [details] [diff] [review] fixes drop target urls ranking Karsten is the SeaMonkey mail owner, I don't know mail code.
Attachment #417605 - Flags: review?(kairo) → review?(mnyromyr)
Attachment #417605 - Flags: review?(mnyromyr) → review+
Keywords: checkin-needed
Comment on attachment 417605 [details] [diff] [review] fixes drop target urls ranking http://hg.mozilla.org/comm-central/rev/a2a524e80244
Attachment #417605 - Attachment description: fixes drop target urls ranking → fixes drop target urls ranking [Checkin: Comment 27]
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 3.1a1
Summary: Unable to open Attached Message Part (Tb3 generates text/html part instead of message/rfc822 for attached mail, Unable to open text attachment by external program) → Unable to open Attached Message Part (this bug:Tb3 generates text/html part instead of message/rfc822 for attached mail, bug 533462:Unable to open text attachment by external program)
We should at least have a litmus test on this, if not a specific test as well.
Flags: in-testsuite?
Flags: in-litmus?
Flags: blocking-thunderbird3.1?
fwiw, I've been using the latest 3.1 builds including this fix, and all appears to work well - essentially the same as it did in 2.x for this feature. Will this make 3.01?
Comment on attachment 417605 [details] [diff] [review] fixes drop target urls ranking a=Standard8 (for both SeaMonkey & Thunderbird)
Attachment #417605 - Flags: approval-thunderbird3.0.1? → approval-thunderbird3.0.1+
Keywords: checkin-needed
Whiteboard: [checkin to comm-1.9.1 branch]
Comment on attachment 417605 [details] [diff] [review] fixes drop target urls ranking Checked into branch: http://hg.mozilla.org/releases/comm-1.9.1/rev/1ff85a13be1e
Attachment #417605 - Attachment description: fixes drop target urls ranking [Checkin: Comment 27] → fixes drop target urls ranking
status-thunderbird3.0: wanted → .1-fixed
Keywords: checkin-needed
Whiteboard: [checkin to comm-1.9.1 branch]
https://litmus.mozilla.org/show_test.cgi?id=9842 V. Fix with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.7) Gecko/20100107 Shredder/3.0.1pre
Status: RESOLVED → VERIFIED
Flags: in-litmus? → in-litmus+
Keywords: verified-thunderbird3.0
I have just tried nightly build from http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-comm-1.9.1-l10n/ dated 07-Jan-2010 cs version on Windows XP SP3 Still not working.
(In reply to comment #35) > Still not working. Please can you include the full version string from help -> About, and provide STR to clarify that you are testing this in the same manner as the bug is described.
(In reply to comment #36) > Please can you include the full version string from help -> About Mozilla/5.0 (Windows; U; Windows NT 5.1; cs; rv:1.9.1.7) Gecko/20100107 Shredder/3.0.1pre > , and provide STR to clarify that you are testing this in the same manner as the bug is described. Do not know, what STR is, but it's problem with opening txt attachments (link to imap or pop3 is given to external program (text editor), instead of file copied to temp)
(In reply to comment #37) > > , and provide STR to clarify that you are testing this in the same manner as the bug is described. > Do not know, what STR is, but it's problem with opening txt attachments (link > to imap or pop3 is given to external program (text editor), instead of file > copied to temp) STR = Steps to reproduce. This bug is about email attachments, not text attachments. The bug you are seeing is bug 533462.
Flags: in-testsuite?
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: