User Agent: Mozilla/5.0 (masking-agent; rv:39.0) Gecko/20100101 Firefox/39.0 Build ID: 20150630154324 Steps to reproduce: I was editing a reply to an eMail which contained an image. The image was copied to my reply when I said to reply to the original eMail. Actual results: I had been trying to reply to an eMail during which time Thunderbird has repeatedly started trying to attach something to my reply after a few minutes even tho I had not asked it to attach anything. I get it to stop trying to do the non-existent attach by saving the eMail in the Drafts folder. (Earlier tho I was unable to save the eMail and lost my reply. I searched through the Drafts and Trash folder using EMACS and my reply was really gone. However that behavior has not repeated.) A while (not long) after saving my reply to Drafts Thunderbird initiated another attach which ran indefinitely. I did some searching on the web using possible keywords and found that other have reported this problem. Three years ago in 2012. Here is the URL: http://forums.mozillazine.org/viewtopic.php?f=39&t=2459519 Part of what I read there was about their eMail which was a reply and which also had a photo in the reply which was copied from the eMail being replied to. My reply also carried an image from the eMail to which I was replying. I resolved NOT to remove the image to see if the problem would occur again. It did only a few minutes after saving my reply. Then I would save again and repeat. Same thing every time with the attach attempt reasserting itself after only a few minutes. After repeating the above several times I finally deleted the photo from my reply. I have worked on the reply for a few hours now and the unprovoked attach has not recurred. Thunderbird is obviously looking for an image it already has but has semi-forgotten (it was still there in the editing buffer before I deleted it) and it begins its search on some sort of timer. Sometimes this problem cannot be stopped by saving the message to Drafts so other badness can happen. ------------- Note a secondary problem: The so-called progress bar which appears when Thunderbird is trying to do an attach and for other behaviors actually measures nothing and uses 100% of available CPU time telling us nothing. Expected results: I should have just been editing my reply without having to stop some "attach" operation which I did not ask for.

PS: The aforementioned problem was seen on a Linux machine (Slackware 14.1). I do not know about other platforms since I do all my work on Linux. I use the latest Thunderbird available to the general public, in this case 38.1.0.

Jeff, on which version of TB did you observe this problem? We've seen this bug before around Bug 532395, it's not eliminated but should have improved in TB 38.

OK, my bug here is a symptom of another bug. It's clear from bug ID=532395, comment 114 by Thomas D. on 2014-04-16 10:01:57 PDT As hinted in Whiteboard field of this bug, this bug is to collect bugs which report the same symptom ("Attaching..." endless spin), but whose causes have not been verified yet. On the other hand, we have (at least) two verified causes for this bug: Bug 453196 Embedded image URL points to another msg and that other msg is deleted before saving/sending (so picture can't be found any more) I did exactly that. I did a reply to the original eMail and then I moved the original and subsequently did a compaction, so the original image was gone from where it had been but the reply copy was still pointing at where the original image had been. This also perfectly explains why there have been comments from people saying the problem is solved when they deleted the image from the reply and then pasted it back in: that changes the pointer to something which exists. Sorry to be so blunt about it but this is an elementary programming bug. You can only point at things which you can control. This has been pointed out by another bug which, as far as I am concerned is a critical bug. Comment 114 then goes on to say: I'm not even sure to what extent this has been acknowledged as a general design problem by developers; but I've done my best to present the problem and evidence from related bugs to support that analysis, and other well-known bug triagers have come to the same conclusion: In a nutshell, all things which are seen in your composition should be copied immediately so that they are in the exclusive control range of your composition, which would solve most if not all of these bugs. Exactly. The real (and critical) bug in this case is: Bug 877159 - (attach-paradigm-fail) [Meta] Tracker bug for attachment paradigm failures - "attach/embed immediate snapshot" VS. "attach/embed later when sending" which developers NEED TO FIX. I think I have properly marked this bug as RESOLVED because it is yet another instance of a separately reported critical bug, 877159, which has yet to be addressed. My thanks to Thomas D. for all his work on pointing out the seriousness of this problem. Thank you, Jeff Barry ------------ PS: And just as an aside there is this: In case you're wondering why it takes so long to fix identified bugs, pls be aware that Mozilla has de-funded TB so development of TB is now done by volunteers (including some Mozilla employees dedicating their spare time). ??? Since I don't follow news from Mozilla would someone be so kind as to point me at the story behind this. Is TB development considered to be complete? Is TB to be replaced? Or what? Thanks in advance.

Hi Jeff, thanks for commenting on your user experience with the problematic attachment design described in bug 877159 (alias: attach-paradigm-fail): bug 877159 - [Meta] Tracker bug for attachment paradigm failures - "attach/embed immediate snapshot" VS. "attach/embed later when sending" Per your comment 4, your specific case is described by Bug 453196, which makes this a duplicate of that. We generally duplicate specific cases against specific bugs, not against meta bugs which are meant to collect/link/meta-analyse specific cases. Thank you for exploring and cross-linking relevant bugs. Fyi, for bugzilla's comment auto-linkification to work, please use the following syntax: comment 4 (linking to a comment from the same bug) bug 532395 (linking to another bug) bug 532395, comment 114 (linking to a comment from another bug) (In reply to Jeff Barry from comment #4) > Sorry to be so blunt about it but this is an elementary programming bug. > You can only point at things which you can control. +1 > My thanks to Thomas D. for all his work on pointing out the seriousness of > this problem. Welcome. It's also pretty hard to understand, and not easy to fix. More so with other serious bugs around, and few developers. > In case you're wondering why it takes so long to fix identified > bugs, pls be aware that Mozilla has de-funded TB so development of > TB is now done by volunteers (including some Mozilla employees > dedicating their spare time). > > ??? Since I don't follow news from Mozilla would someone be so kind as to > point me at the story behind this. Is TB development considered to be > complete? Is TB to be replaced? Or what? Thanks in advance. Mozilla decided to focus and bundle their manpower on other products like Firefox OS which were considered more innovative and demanding attention; consequently, development of TB is now fully in the hand of a relatively small group of volunteers, with infrastructure support from Mozilla. TB development definitely isn't complete in terms of bugs and innovation. Volunteer community has just released a worthwhile milestone, TB 38, and we're doing our best to improve the product with the limited resources at hand, while also exploring models of expanding those resources (financially). TB is here to stay.