Closed Bug 161775 Opened 18 years ago Closed 13 years ago
Reply shouldn't quote inline attachments
From Bugzilla Helper: User-Agent: Mozilla/4.77 [en] (X11; U; Linux 2.4.2-2 i686) BuildID: 2002072514 When replying inline, I really do not want attachments inlined as well, which happens if the attachment is either HTML or text. This is especially painful when someone attaches a large text file. Hitting the reply button usually stalls Mozilla for a fair bit. Reproducible: Always Steps to Reproduce: 1.Send e-mail to self with large text attachment. 2.Enable reply inline. 3.Try to reply to e-mail from step 1. Actual Results: Attachments are inlined, and Mozilla stalls. Expected Results: Attachment should not be inlined. IMHO attachments shouldn't be included in a reply. This was the way Messenger 4.x used to work... Perhaps not a bug per se, but Mozilla has crashed on me trying to deal with large attachments.
seems similar to Bug 65794
Ah. Just looked at that bug. I'm not sure if it's a dup, since 65794 and friends deal with viewing a message, and this has more to do with message composition. Of course, the fix for one might work for both.
*** Bug 173230 has been marked as a duplicate of this bug. ***
*** Bug 184712 has been marked as a duplicate of this bug. ***
This is the same thing as bug 144311 (or 144311 is the same as this;-))
I agree -- this looks like the bug I filed 144311. The one I filed seven months ago and hasn't even gotten an acknowledgement from the assigned engineer.
in Mozilla 1.3, you can turn off display attachment inline. That also affect the way we do the reply. When we reply, we quote exactly what you see in the message display. If you don't want attachment displayed inline to be part of the reply, either you remove it manually or you turn off the display attachment inline using the menu view/Display Attachments Inline. WFM
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago
Resolution: --- → WORKSFORME
Please REOPENEN - objections: I dissagree with your solution of this bug. I want to see attachments inline if possible, but the attachments should not to be inlined in reply. > When we reply, we quote exactly what you see in the message display. *THIS* IS THE BUG. From your solution I see this bug is deeper in mailnews architecture, where during reply you have no access to original text of the message without attachments - I think this should be fixed (and IMHO this should not be to hard, since you can include hidden separator between message text and inline displayed attachments). >If you don't want attachment displayed inline to be part of the reply, >either you remove it manually This is nice suggestion, but try to reply to a messege with 300kB text attached - it took 15 seconds on my Celeron 900MHz machine to display reply window, with 100% processor usage and whole mozilla freezed. Also scrolling down the message to select the attachment and not to select a signature before I hit [Del] key it took additional 20-30 seconds of ugly manual work.
I agree with Ivan. It would be nice if Mozilla could just duplicate the behavior in NS 4.x. I don't want to have to remember to turn "View Attachments" off to reply to message that have huge text attachments. The huge lag hit when you forget is too big a penalty to pay.
I, too, agree with Ivan that attachments shouldn't be quoted. But, at the very least the UI should be responsive during the reply (see my comments in bug 184712). Maybe this part can be fixed via bug 144311?
you were right, 4.x never inculde inline attachment in a reply! Reopen...
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
Target Milestone: --- → mozilla1.3beta
I just replied to an email to a number of family members. The email was a reply to one a recieved earlier with 6mb of holiday photos. As I view attachments inline, it meant the rather unneccesarily large email attachments was again sent to everyone. I dont envy the ones with dial ups.... :) I did not expect attachments to be included in replies, and espicially not to be inline any more. While I was composing the reply the attachments box was empty so i didnt think the photos was attached as they normally are not with replies. Now that I am aware of it I will have manually either untick-reply-tick, or delete attachments in reply. As a few have now commented on this , should it not be taken off unconfirmed?
Jean François, you said you would reopen it http://bugzilla.mozilla.org/show_bug.cgi?id=161775#c11 But it is still "unconfirmed" !! I agree with all user comments: - nobody expects attachments to be included in a reply (and everybody knows that he would need to use forward in case he wants to send attachments again) - content of the reply should'nt be based on the viewing option of the original message (does "view attachments inline" even impacts the composition of a new message ? if you drag and drop an image in the composition window, you'll view it inline whatever the setting for attachment viewing is !?) - if mozilla is primarly targeted to previous users of NS4, there is no reason to surprise and annoy them with such an assumption last, it should be possible to drag and drop attachments from a recieved message to the composition window (attachment or inline)
about my last comment : -- last, it should be possible to drag and drop attachments from a recieved message to the composition window (attachment or inline) -- it works fine in 1.5rc1 Looking further to the initial subject, it appears that attachments of a content type that doesn't support inline viewing are never attached again. On the opposite, attachments of a compatible content type are displayed in both the attachment window list and inline (when viewing the message) BUT, when replying, attachements are only displayed in-line in the composition window, and don't appear in the attachment window Then, when they appear at the bottom of the message, hidden by scrolling, you may never see that you have in-line images included in your reply, and this is really annoying !!
I agree two. We get a lot of comma seperatted databases down sometimes as .csv sometimes as txt. When I forward a e-mail with this large .csv database in text format to him. It inlines it and makes it unusable. I want to see it in-line maybe but mainly it must be sent as a attachment
on winxp build 1.7a 20040208 comment #15 isn't valid any more : it isn't possible to drag received attachment to any location !!!... and inline content is still resent when replying, and doesn't show up in the list of attached content... arrrghh !!
I don't understand Comment #16 about Comment #15. I wan't talking about dragging. Where did you read that?
sorry, it was about comment #14 (my previous one) Regards
*** Bug 144311 has been marked as a duplicate of this bug. ***
*** Bug 216981 has been marked as a duplicate of this bug. ***
*** Bug 250174 has been marked as a duplicate of this bug. ***
I was about to file another dupe of this bug... I think there are really two issues here: (1) should attachments be included in replies? (2) why does it take such a long time to create the composition window containing such a reply? I think that if (2) were solved people would worry less about (1) (I know I would). Has anyone investigated the performance issue? It seems to me that viewing a message with a 100kb inline text attachment takes only a second whereas creating a reply window takes at least a minute. Is there some unnecessary O(n^2) stuff going on?
I don't think that's true. Even if it loads fast, I don't want to have to highlight 100k worth of text (scroll scroll scroll scroll). As for #1, I don't think they should be included. Forwards, yes, replies, no. And even if they were, they should remain separate attachments and not inlined (which is what this bug was originally opened for).
I agree, and would recommend taking this a step further and NOT displaying attachments inline when viewing a message unless the user opts to do so. It's pretty rough on the eyes when someone sends you 4 attachments. Having a small tree that you could collapse/expand would make this feature a lot more useful.
A little more than a "me too" comment... Regardless of performance, I also would like "display attachments inline" to not effect the content of quoted replies. Would there be a "quick fix" type of solution by having "reply" first read and save the value of "display attachments inline", turn it off if it was on, do the current work of "reply", and then restore the original value of "display attachments inline"? That might not be the best fix, but if it was a quick fix, I'd be happy to get a fix, rather than an architectural delight :)
And another comment: the idea of a tree to turn on enabled/disabled attachments is a great idea, but probably belongs in a different bug. If so, and if I should open it as a new bug, let me know. Perhaps the existing attachment pane could have a 3-value check-box... the initial values of the check box would be based on whether "display attachments inline" is set or not, and whether the attachment is of a type that can be displayed inline or not. The three values would be: check box disabled for types of attachments that cannot be displayed inline check box enabled and checked for attachments that are displayed check box enabled and not checked for attachments that are not displayed As an alternative, when "display attachments inline" is on, checking or unchecking a box would add/remove the display of the attachment to the message content. When "display attachments inline" is off, the checkboxes would be radio buttons, and there would also be one for the original message, and only the attachment for the selected radio button would be displayed in the message window.
OS: Linux → All
Hardware: PC → All
Summary: Reply inline shouldn't inline attachments → Reply shouldn't quote inline attachments
Target Milestone: mozilla1.3beta → ---
*** Bug 206681 has been marked as a duplicate of this bug. ***
*** Bug 177703 has been marked as a duplicate of this bug. ***
*** Bug 312707 has been marked as a duplicate of this bug. ***
Just to stress how *long* it takes the reply window when there is a large attachment inline... I have a piece of e-mail with a 370K text attachment. It pegs my 3.2G CPU for maybe 60 seconds when I hit reply. I thought it was hung for good and killed the app before I sought out this bug thread. This bug is 3 years old!
*** Bug 283554 has been marked as a duplicate of this bug. ***
*** Bug 339212 has been marked as a duplicate of this bug. ***
I don't know if replying to messages with text attachments shown in-line is O(n^2) or not, but yesterday I replied to a message with an 8MB text attachment and Thunderbird locked up with 100% CPU usage for 2 hours on this 2.2GHz P4 laptop before I killed it. Taking over 2 hours to process 8MB means it was processing less than 600 bytes per second. That's very slow! I saved the attachment to disk to take a look at it. It ended up as a 6018011 byte file on disk. I asked the sender to send it again after renaming it to a ".log" file, and saved it again. That time when I saved it to disk it was only 6017944 bytes - 67 bytes shorter. The 67 bytes difference were: 61 bytes added to the start of the file, saying: <div class="moz-text-flowed" style="font-family: -moz-fixed"> and 6 bytes added to the end of the file, saying: </div> Now the .txt attachment was in some kind of unicode (2 bytes per character), so when Thunderbird added those strings to the start and end of the file, it stopped my editor from recognising the text as being unicode. Why is Thunderbird adding its own text to my text attachments before saving them to disk? I just want what was send! (The sender uses Outlook Express, so it's unlikely that the "moz-text" string originated there).
howdy y'all,  my tbird info ... Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:18.104.22.168) Gecko/20060308 Thunderbird/22.214.171.124 - Build ID: 2006030803  an extension to do this [and other things] exists. lookee ... https://nic-nac-project.de/~kaosmos/changequote-en.html " From 0.4.11 version you've also an option to reply stripping off the inline attachments (cfr. https://bugzilla.mozilla.org/show_bug.cgi?id=161775 ) " take care, lee
(In reply to comment #33) > 61 bytes added to the start of the file, saying: > <div class="moz-text-flowed" style="font-family: -moz-fixed"> > [...] > Now the .txt attachment was in some kind of unicode (2 bytes per character), > so when Thunderbird added those strings to the start and end of the file, it > stopped my editor from recognising the text as being unicode. > > Why is Thunderbird adding its own text to my text attachments before saving > them to disk? I just want what was send! (The sender uses Outlook Express, > so it's unlikely that the "moz-text" string originated there). Chris Moore: This symptom is bug 121297.
*** Bug 358870 has been marked as a duplicate of this bug. ***
Bug 358124 provided a patch that fixes this for text/plain attachments. There may be some other MIME types that are affected, but in the testing I've been able to do in a crashing trunk build, image/png, image/jpeg and message/rfc822 attachments are always still included, as were most (but not all) of the text/html cases I tried. Don't know if that inconsistency is something inherent in the fix, in the MIME of the messages, or in the instability of the crashing build.
(In reply to comment #37) > image/png, image/jpeg and message/rfc822 > attachments are always still included, as were most (but not all) of the > text/html cases I tried. Don't know if that inconsistency is something > inherent in the fix, in the MIME of the messages, or in the instability of > the crashing build. After turning off inline spell-checking, I'm no longer seeing crashes in my trunk build. I tested every message I could find with text/html attachments and they all were getting included on reply, so I'm guessing the instances I saw before where that wasn't happening were because of crash-based instability. After running a bunch of these tests, I'm on the fence about including message/rfc822 attachments. One likely scenario is, someone has gotten a copy of an earlier message in a forward to bring them into the conversation, and a reply may well want to reference the quoted text. OTOH, I have a bunch of test messages which have a large number of rfc822 attachments, and replying to these, I definitely don't want them quoted and would prefer not to have to select everything to delete it. Of course, I can turn off Display Attachments Inline before replying; and this seems to be a much less likely scenario in the real world anyway. But the text/html and image/* types still ought not to be quoted. I also noticed that if you reply in plain text to a message that's displaying an image inline, altho you won't get the image, you will still get the row of dashes indicating the <hr> separate used in the display. (As noted in comment 14, in the case where the attachment is actually desired in the reply, it can be dragged from the message window to the compose window's attachment panel.)
This is still a mojor problem for me too
I like Thunderbird, but this is one of the issues where I am considering moving back to Outlook. It is a nasty 'feature' of Thunderbird that only creates internet/e-mail pollution TMHO because most people do not want to include the megabyte attachments (e.g. pictures) in a reply. Is this problem marked as a problem now? In this problem history I did see it was canceled, then re-opened again. But in the list it is still marked as NEW, which I do not understand. This problem should be considered as a serious problem which is already 5 years old. Suggestion: make it an optional feature in the settings to include the attchments in a reply, where default = no attachments in reply.
(In reply to comment #40) > I like Thunderbird, but this is one of the issues where I am considering moving > back to Outlook. It is a nasty 'feature' of Thunderbird that only creates > internet/e-mail pollution TMHO because most people do not want to include the > megabyte attachments (e.g. pictures) in a reply. > > Is this problem marked as a problem now? > In this problem history I did see it was canceled, then re-opened again. But in > the list it is still marked as NEW, which I do not understand. > This problem should be considered as a serious problem which is already 5 years > old. > > Suggestion: make it an optional feature in the settings to include the > attchments in a reply, where default = no attachments in reply. > I agree with this guy. It is a major pain in the rump to be highlighting sections of messages to selectively reply to emails , for the sole purpose of getting rid of attachments in replies. Surely, the attachment tab in TB could have this feature enabled as default. If nothing else it would save googals of server space with messages like " nice picture of your kids" with the pictures attached!
Here's a proposed fix for making sure all inline attachments are not included in a reply. Note that this undoes the change for Bug 358124, which prevented only inline plain text attachments from being included in replies.
It great that a fix is forthcoming. The only problem for me is how to apply the patch? Will there be a "patched" version to download and install or is there some other process?
Comment on attachment 272598 [details] [diff] [review] Proposed patch I'm not really sure what the right behavior is, but I'm willing to try this since folks seem to have liked the work David did already for inline plain text attachments.
Attachment #272598 - Flags: superreview?(mscott) → superreview+
David: have you had a chance to look at this patch?
Comment on attachment 272598 [details] [diff] [review] Proposed patch I'm not sure this is the right thing to do either, but I'm willing to try it.
Attachment #272598 - Flags: review?(bienvenu) → review+
Checking in mailnews/mime/src/mimei.cpp; /cvsroot/mozilla/mailnews/mime/src/mimei.cpp,v <-- mimei.cpp new revision: 1.87; previous revision: 1.86 done Checking in mailnews/mime/src/mimetpla.cpp; /cvsroot/mozilla/mailnews/mime/src/mimetpla.cpp,v <-- mimetpla.cpp new revision: 1.64; previous revision: 1.63 done ->FIXED, thanks for the patch!
Status: ASSIGNED → RESOLVED
Closed: 17 years ago → 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9 M9
(fixed the overlong line before checking in)
(In reply to comment #40) > > Suggestion: make it an optional feature in the settings to include the > attchments in a reply, where default = no attachments in reply. I drafted a patch for making this conditional based on a new preference, this is open for discussion in bug 384599.
You need to log in before you can comment on or make changes to this bug.