User Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20100101 Firefox/15.0.1 Build ID: 20120905151427 Steps to reproduce: reply to an email that had images present in a footer Actual results: a box comes up saying "attaching.." , thunderbird seems to get stuck trying to attach these images, even though they are not local. Expected results: the email should of sent. workaround: delete any images in the original email body.

seems to be easier to demonstrate with "reply all" instead of "reply" and with a few recipients.

Are you looking phenomenon of bug 532395?

I think this should be closed as dupe of bug 532395. We can't expect reporter to do detailed analysis so as to verify that this is a strict technical duplicate of bug 532395 in it's current shape. I find it a bit worrying that we are keeping so many bugs about the same symptom open. Perhaps we need some sort of tracker bug to collect all these "mails with inline images fail" bugs. Well for the time being, I'll mark this connected with bug 532395 pending further analysis (for ease of tracking), which I hope is in line with WADA's stricter policy of duplication.

(In reply to Thomas D. from comment #3) > I think this should be closed as dupe of bug 532395. As I wrote in bug 817245 comment #2, several kinds of problem is involved in bug 532395, although the produces same external phenomenon of "Attaching...". Thomas D, this bug is dup of which case reported in bug 532395?.

As I wrote in bug 817245, "Image location" of embed image in composing/editing HTML mail is shown like next, where nnn=Offset(local mail folder) or nnn=UID(IMAP mail folder). > mailbox:.../Inbox%3Ennn?part=1.2&filename=EmbedImage.jpg > mailbox:.../Drafts%3Ennn?part=1.2&filename=EmbedImage.jpg > imap://user-id@imap.gmail.com:993/fetch%3EUID%3E/INBOX%3Ennn?part=1.2&filename=EmbedImage.jpg > imap://user-id@imap.gmail.com:993/fetch%3EUID%3E/Drafts%3Ennn?part=1.2&filename=EmbedImage.jpg And, nnn=Offset(local mail folder) or nnn=UID(IMAP mail folder) of a mail is shown as "Order Received" column value by Tb. Bug opener, if you will see problem again, view "Image Location", check mail of Offset=nnn or UID=nnn which is pointed by the "Image Lcation" in mail folder which is pointed by the "Image Location", and check whether your problem is same issue as bug 453196/bug 817245 or not, please.

(In reply to WADA from comment #4) > (In reply to Thomas D. from comment #3) > > I think this should be closed as dupe of bug 532395. > > As I wrote in bug 817245 comment #2, several kinds of problem is involved in > bug 532395, although the produces same external phenomenon of "Attaching...". > Thomas D, this bug is dup of which case reported in bug 532395?. I don't know. But I'm worried about the workflow concerning these bugs. Keeping all them open separately while not fixing the known causes and then see what's left seems a non-sustainable approach to me. We can get tens of duplicates of the known causes, who will analyse all of them? I think the better solution is: (In reply to Thomas D. from bug 791973, comment #4) > (In reply to WADA from comment #2) > > Is bug 532395 for any case of "attaching..."? > Currently, probably yes. > > But I think what we should do is create a new Meta/Tracker bug (to sideline > the cesspool of bug 532395) to collect *all* cases with symptoms of > "Composition with inline images fails with 'Attaching...'". Then we can just > add them there for ease of tracking, even without further analysis. That > Meta bug should not include analysis. Analysis could still be continued in > bug 532395 if needed, or in another new Meta-Analysis bug starting with > Wada's comment 2. 1) collect all bugs with same symptoms somewhere (new Meta tracker) 1b) even possibly close them immediately and ask reporter to only reopen if they have evidence that cause of their problem is different from bug 453196 or bug 817245. 1c) try to centralize analysis of unknown/other suspected causes in bug 532395, or better, in another new meta-analysis bug; then spin off any consolidated findings into separate bugs, like WADA did with bugs of 2) below. 2) fix known causes bug 453196 / bug 817245 3) After fix of 2), (close down if not done in 1b, and) ping all bugs with same symptoms, and ask reporter to reopen if they still see their bug after updating to version with fix for 2) 4) Then continue analysis for remaining problems with a much smaller set of bugs (or even somewhere centralized again, see 1c).

(In reply to Thomas D. from comment #6) > I don't know. But I'm worried about the workflow concerning these bugs. > Keeping all them open separately while not fixing the known causes and then > see what's left seems a non-sustainable approach to me. If dependency is set to a main bug or some important bugs, notification of responsee from some one is sent to us from B.M.O. So I thought we can analyze many relevant bugs via dependency tree. But if you don't think so, please do as you like. I'll focus on clear/specific problem of bug 453196 and bugs referred in bug 453196 and bug 817245 only, and I can forget and ignore other "unclear and duped to also unclear bug report by you" bug reports immediately.

Closing as dup of bug 532395. If duping is wrong, please re-open with detailed explanation about difference of your case from that bug.