889069 - TB hangs when sending a reply email (coincidentally having the word "attach" in original email body)

Status: RESOLVED DUPLICATE of bug 817245

(Thunderbird :: Untriaged, defect)

Description

[B.Kaatz]

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.43 Safari/537.31

Steps to reproduce:

1. Received email with text in the message body similar to the following:

"**********    Confidentiality Notice    **********
This electronic transmission and any attached documents or other writings are confidential and are for the sole use of the intended recipient(s) identified above. This message may contain information that is privileged, confidential or otherwise protected from disclosure under applicable law. If the receiver of this information is not the intended recipient, or the employee, or agent responsible for delivering the information to the intended recipient, you are hereby notified that any use, reading, dissemination, distribution, copying or storage of this information is strictly prohibited. If you have received this information in error, please notify the sender by return email and delete the electronic transmission, including all attachments from your system."

2. Clicked "Reply" and composed a response.

3. Clicked "Send".


Actual results:

1. "Sending Message" dialog box pops up with "Status: Attaching ..." and stays there with Progress Bar continuing to spin indefinitely.


Expected results:

Two possible resolutions that I can see:

1.) Have the message go out as-is without the non-existent attachment.

or, 

2.) Have the same pop-up dialog come up as when composing a message with the word "attach" (or "attached" or "attachment") in the message body, asking if you want to attach a file now or just send without an attachment.

Comment 1

[WADA:World Anti-bad-Duping Agency]

Problem of bug 817245?

Comment 2

[Wayne Mery (:wsmwk)]

(In reply to WADA from comment #1)
> Problem of bug 817245?

Kaatz, do you agree?

Does this problem cause Thunderbird to hang?  Or just that error dialog is stuck?

Comment 3

[B.Kaatz]

Just the sending dialog gets stuck on that "Status: Attaching..." dialog. 

You can cancel out of the sending, and it seems that if you break up all the instances of the word "attach" within the reply email, you can send it without it trying to attach a non-existent file.

Comment 4

[Thomas D. (:thomas8)]

(In reply to B.Kaatz from comment #3)
> Just the sending dialog gets stuck on that "Status: Attaching..." dialog. 
> 
> You can cancel out of the sending, and it seems that if you break up all the
> instances of the word "attach" within the reply email, you can send it
> without it trying to attach a non-existent file.

No, it can't be that. Must be coincidental. Simple words in body ("attach") cannot possibly cause a hang of this sort. Perhaps when they would look like a msg header, but that's not reported here. True cause probably something like bug 817245, as suspected by WADA. But those bugs are hard to see from surface.

b.kaatz, can you provide the source of an affected original msg to which the reply fails? Remove private data from text source, then "add an attachment" above

Comment 5

[B.Kaatz]

(In reply to Thomas D. from comment #4)
> 
> No, it can't be that. Must be coincidental. Simple words in body ("attach")
> cannot possibly cause a hang of this sort. Perhaps when they would look like
> a msg header, but that's not reported here. True cause probably something
> like bug 817245, as suspected by WADA. But those bugs are hard to see from
> surface.
> 
> b.kaatz, can you provide the source of an affected original msg to which the
> reply fails? Remove private data from text source, then "add an attachment"
> above

Sorry about the delay.  Got buried in a rush project.
Looking for a test case email to get to you, but a quick note:
If the email can keep prompting you to add an attachment for just putting one (or more) of the words "attach", "attached" or "attachment" into the email, then why could it not hang trying to attach an attachment *it* expects to be there?

Comment 6

[Thomas D. (:thomas8)]

(In reply to B.Kaatz from comment #5)
> (In reply to Thomas D. from comment #4)
> > 
> > No, it can't be that. Must be coincidental. Simple words in body ("attach")
> > cannot possibly cause a hang of this sort.
> If the email can keep prompting you to add an attachment for just putting
> one (or more) of the words "attach", "attached" or "attachment" into the
> email, then why could it not hang trying to attach an attachment *it*
> expects to be there?

B.Kaatz, thanks for reply and critical question, I encourage that :) I've recently handled bugs of both categories: bugs to improve the attachment reminder code which checks for the words, and bugs where TB gets stuck (which is not necessarily a hang) when trying to assemble the message and attach things. So I believe I've got a reasonably good idea of the mechanisms at work, and what kind of bugs we can expect (albeit I don't claim to know *all* the details). I was only referring to your comment 3 and imo it cannot possibly occur with the causal connections as you describe them:

(In reply to B.Kaatz from comment #3)
> Just the sending dialog gets stuck on that "Status: Attaching..." dialog. 

Yes. We know that this bug happens, as seen e.g. on bug 817245.

> You can cancel out of the sending

If you can still cancel out, the program is still responding, so technically, it's not a hang. But we get what you're trying to say, it's "stuck" and not proceeding as expected, and would try sending forever unless interrupted. True.

> and it seems that if you break up all the
> instances of the word "attach" within the reply email, you can send it
> without it trying to attach a non-existent file.

It's this last part which is technically impossible: attachment words that you type will trigger the notification bar (which works), and will set certain flags depending how you (don't) reply to the notification. Those flags will just trigger the "Did you forget an attachment?" dialogue, which again works as currently designed. Otherwise the words-checking routine and the attachment notification are entirely unrelated to the actual functions of attaching a file at send time (or save/close draft time), so if you are seeing a "Status: Atttaching..." msg somewhere, it means that there is some sort of real attachment that is already attached or linked to the message (which can be e.g. an inline image, even a hidden/invisible one from a signature, or a file which you attached yourself and which now can't be found for whatever reason). So at that time, you're no longer in the attachment reminder code, you're actually in the code which tries to assemble the message for saving or sending. Words in body are not considered by that message-assembling code, so the odds are 99:1 that this is unrelated. I hope that explains it.

Comment 7

[B.Kaatz]

Attachment: Email file that exhibits the stuck "Attaching..." behavior

This confirms that while the behavior still exists, it is *not* tied to the word "attach" being in the body of the email.  
Perhaps, it is due to the image that the original sender uses as part of their signature.

Comment 8

[B.Kaatz]

(In reply to Thomas D. from comment #6)
> (In reply to B.Kaatz from comment #5)
> > (In reply to Thomas D. from comment #4)
> > > 
> > > No, it can't be that. Must be coincidental. Simple words in body ("attach")
> > > cannot possibly cause a hang of this sort.
> > If the email can keep prompting you to add an attachment for just putting
> > one (or more) of the words "attach", "attached" or "attachment" into the
> > email, then why could it not hang trying to attach an attachment *it*
> > expects to be there?
> 
> B.Kaatz, thanks for reply and critical question, I encourage that :) I've
> recently handled bugs of both categories: bugs to improve the attachment
> reminder code which checks for the words, and bugs where TB gets stuck
> (which is not necessarily a hang) when trying to assemble the message and
> attach things. So I believe I've got a reasonably good idea of the
> mechanisms at work, and what kind of bugs we can expect (albeit I don't
> claim to know *all* the details). I was only referring to your comment 3 and
> imo it cannot possibly occur with the causal connections as you describe
> them:
> 
> (In reply to B.Kaatz from comment #3)
> > Just the sending dialog gets stuck on that "Status: Attaching..." dialog. 
> 
> Yes. We know that this bug happens, as seen e.g. on bug 817245.
> 
> > You can cancel out of the sending
> 
> If you can still cancel out, the program is still responding, so
> technically, it's not a hang. But we get what you're trying to say, it's
> "stuck" and not proceeding as expected, and would try sending forever unless
> interrupted. True.
> 
> > and it seems that if you break up all the
> > instances of the word "attach" within the reply email, you can send it
> > without it trying to attach a non-existent file.
> 
> It's this last part which is technically impossible: attachment words that
> you type will trigger the notification bar (which works), and will set
> certain flags depending how you (don't) reply to the notification. Those
> flags will just trigger the "Did you forget an attachment?" dialogue, which
> again works as currently designed. Otherwise the words-checking routine and
> the attachment notification are entirely unrelated to the actual functions
> of attaching a file at send time (or save/close draft time), so if you are
> seeing a "Status: Atttaching..." msg somewhere, it means that there is some
> sort of real attachment that is already attached or linked to the message
> (which can be e.g. an inline image, even a hidden/invisible one from a
> signature, or a file which you attached yourself and which now can't be
> found for whatever reason). So at that time, you're no longer in the
> attachment reminder code, you're actually in the code which tries to
> assemble the message for saving or sending. Words in body are not considered
> by that message-assembling code, so the odds are 99:1 that this is
> unrelated. I hope that explains it.

I apologize, Thomas, for the misperception on my part.  (Although, that does make it seem stranger that it *did* allow me to send the previous emails after breaking up the words.)
I finally found the behavior again on a completely separate email (attached above), and that email did not have the word "attach" anywhere in the body.  However, it *did* have an image that the original sender uses for his signature.  So, is this a duplicate of bug 817245?

Thanks again for your patience and hard work.

Comment 9

[Thomas D. (:thomas8)]

(In reply to B.Kaatz from comment #8)

Thanks B. Kaatz, your cooperation to narrow down this bug is very much appreciated. I've seen less cooperative folks, even an occasional dev, so I know what I'm talking about.

> (In reply to Thomas D. from comment #6)
> > (In reply to B.Kaatz from comment #5)
> > > (In reply to Thomas D. from comment #4)
> > B.Kaatz, thanks for reply and critical question, I encourage that :) I've
> make it seem stranger that it *did* allow me to send the previous emails
> after breaking up the words.)

Yeah, strange things do happen in TB, albeit they usually have some technical cause ;)
Sometimes such errors appear very obscure, e.g. there's a big difference if you only have one composition window open or more than one, because internally, we recycle the entire window which sometimes leads to strange effects where some people see bugs which others don't see - they are doing exactly the same steps but in internally different kinds of windows, which you'll hardly ever notice from symptoms unless you *know* there is this window recycling, controlled by hidden preference in config editor.

> I finally found the behavior again on a completely separate email (attached
> above), and that email did not have the word "attach" anywhere in the body. 
> However, it *did* have an image that the original sender uses for his
> signature.  So, is this a duplicate of bug 817245?

I think that's very likely.
I assume what you attached here is the source of your draft message (and it's not the complete msg, only the HTML part). As you said, there's an image in the signature:

<img id="Picture_x0020_1"
src="mailbox:///home/user/.thunderbird/XXXXXXXX.default/Mail/Local%20Folders/Drafts?number=903024121&amp;header=quotebody&amp;part=1.2&amp;filename=image001.jpg"
            alt="canon" border="0" height="96" width="169">

That image is referenced from draft #903024121 in your "Local Folders/Drafts" folder.
I bet that draft is either non-existent, or it's not the original one which has the image (or at least that's how it probably WAS at the time when this error occured).
You could do the following to check:

1) open your "Local Folders/Drafts" folder
2) From msg list's column picker (upper right corner of column headers), pick "Order received", and sort by that column (click column header).
3) Look for draft having value of 903024121 in "Order received" column.
4) Verify these:
a) Does msg 903024121 exist in that folder?
b) Is it the original msg replied to/forwarded?
c) Is the image "image001.jpg" contained in source of that msg (Ctrl+U to view source in msg reader)?

I suspect that due to bug 817245, auto-compact in background renumbered your draft messages while you were composing, so the reference to the image breaks, and then your draft starts to complain when sending because it can no longer find the image.
That implies and explains the erratic occurence of this bug - if you switch off auto-compact and repeat all your steps starting out from the original msg replied to/forwarded, it'll probably work.
Even with auto-compact on, at the right times you will succed with your steps without seeing the bug.

> Thanks again for your patience and hard work.

I truly believe that constructive doubt is helpful for improving the product. Also, mutual respect is absolutely crucial, and again, I've seen bugs fail miserably due to lack of cooperation, benevolent listening and mutual respect. As for patience, it also relates to the factor of time; not everybody will have the time (and patience, and wordpower ;)) to do so...

Comment 11

[jheidelbauer]

Comment on attachment 806974 [details]
Email file that exhibits the stuck "Attaching..." behavior

><html>
>  <head>
>    <meta content="text/html; charset=ISO-8859-1"
>      http-equiv="Content-Type">
>    <title>Re: Server Configuration</title>
>  </head>
>  <body bgcolor="#FFFFFF" text="#000000">
>    <div class="moz-cite-prefix"><font face="Times New Roman, Times,
>        serif">Well,<br>
>        <br>
>        &nbsp;&nbsp;&nbsp; For smaller agencies, you are correct that
>        this might be sufficient.&nbsp; There might be an issue with no
>        PCIe-16 slot, but Petros is running that down, as of this
>        writing.&nbsp; <br>
>        <br>
>        &nbsp;&nbsp;&nbsp; But, for larger implementations (e.g. 
>        ), we would still want the capability of the dual-socket,
>        I'm pretty sure.&nbsp; The resources that are used serving up
>        multiple connections to the webapp while simultaneously doing
>        the processing of one or more acquisition-station clusters can
>        pin a processor pretty easily.&nbsp; So, do we have an idea of
>        where we are headed for that level of hardware yet?<br>
>        <br>
>      </font>
>      <pre class="moz-signature" cols="72">--
><br>Regards,
>
>XXXXXXXXX
>Senior Developer
>Head of Technical Services
>XXXXXXXXXXXXXXXXXXXX
>XXXXXXXXXXXXXXXXXXXX
>http://www.XXXXXXXXXXXXXXXXXXXX
></pre>
>      On 09/16/13 11:22, XXXXXXXXXXXXXXXXXXXX wrote:<br>
>    </div>
>    <blockquote
>cite="mid:CE420CAB1FFDAD43AB211D5954FEA4851DDA2A80@XXXXXXXXXXXXXXXXXXXXXX"
>      type="cite">
>      <meta http-equiv="Content-Type" content="text/html;
>        charset=ISO-8859-1">
>      <meta name="Generator" content="Microsoft Word 12 (filtered
>        medium)">
>      <!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
>o\:* {behavior:url(#default#VML);}
>w\:* {behavior:url(#default#VML);}
>.shape {behavior:url(#default#VML);}
></style><![endif]-->
>      <style><!--
>/* Font Definitions */
>@font-face
>	{font-family:"Cambria Math";
>	panose-1:2 4 5 3 5 4 6 3 2 4;}
>@font-face
>	{font-family:Calibri;
>	panose-1:2 15 5 2 2 2 4 3 2 4;}
>@font-face
>	{font-family:Tahoma;
>	panose-1:2 11 6 4 3 5 4 4 2 4;}
>/* Style Definitions */
>p.MsoNormal, li.MsoNormal, div.MsoNormal
>	{margin:0in;
>	margin-bottom:.0001pt;
>	font-size:11.0pt;
>	font-family:"Calibri","sans-serif";}
>a:link, span.MsoHyperlink
>	{mso-style-priority:99;
>	color:blue;
>	text-decoration:underline;}
>a:visited, span.MsoHyperlinkFollowed
>	{mso-style-priority:99;
>	color:purple;
>	text-decoration:underline;}
>p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
>	{mso-style-priority:99;
>	mso-style-link:"Balloon Text Char";
>	margin:0in;
>	margin-bottom:.0001pt;
>	font-size:8.0pt;
>	font-family:"Tahoma","sans-serif";}
>span.EmailStyle17
>	{mso-style-type:personal-compose;
>	font-family:"Calibri","sans-serif";
>	color:windowtext;}
>span.BalloonTextChar
>	{mso-style-name:"Balloon Text Char";
>	mso-style-priority:99;
>	mso-style-link:"Balloon Text";
>	font-family:"Tahoma","sans-serif";}
>.MsoChpDefault
>	{mso-style-type:export-only;}
>@page WordSection1
>	{size:8.5in 11.0in;
>	margin:1.0in 1.0in 1.0in 1.0in;}
>div.WordSection1
>	{page:WordSection1;}
>--></style><!--[if gte mso 9]><xml>
><o:shapedefaults v:ext="edit" spidmax="2050" />
></xml><![endif]--><!--[if gte mso 9]><xml>
><o:shapelayout v:ext="edit">
><o:idmap v:ext="edit" data="1" />
></o:shapelayout></xml><![endif]-->
>      <div class="WordSection1">
>        <p class="MsoNormal">Hey Guys,<o:p></o:p></p>
>        <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
>        <p class="MsoNormal">This is the server board/processor combo I
>          was thinking. I am forced to change at this point as I was
>          able to grab what I needed off ebay, but that is not really
>          how I am supposed to do it. We can test this one out with the
>          Minneapolis upgrade. The specifications are pretty much
>          exactly the same on the processor and it HAS THE INTEGRATED
>          GRAPHICS.<o:p></o:p></p>
>        <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
>        <p class="MsoNormal">The motherboard is scaled down slightly as
>          it only has one socket for a CPU. Having both on there was
>          overkill. Please take a quick look and let me know if any
>          issues stand out to you.<o:p></o:p></p>
>        <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
>        <p class="MsoNormal"><a moz-do-not-send="true"
>            href="http://ark.intel.com/products/71385/">http://ark.intel.com/products/71385/</a><o:p></o:p></p>
>        <p class="MsoNormal"><a moz-do-not-send="true"
>href="http://ark.intel.com/products/65728/Intel-Xeon-Processor-E3-1265L-v2-8M-Cache-2_50-GHz?wapkw=bx80637e31265l2">http://ark.intel.com/products/65728/Intel-Xeon-Processor-E3-1265L-v2-8M-Cache-2_50-GHz?wapkw=bx80637e31265l2</a><o:p></o:p></p>
>        <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
>        <p class="MsoNormal">Thanks,<br>
>          JH<o:p></o:p></p>
>        <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
>        <p class="MsoNormal"><b>XXXXXXXXXXXXXX<o:p></o:p></b></p>
>        <p class="MsoNormal">XXXXXXXXXXXXXX<o:p></o:p></p>
>        <p class="MsoNormal"><i>XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX<o:p></o:p></i></p>
>        <p class="MsoNormal"><a moz-do-not-send="true"
>            href="[e-mail]">[e-mail]</a><o:p></o:p></p>
>        <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
>        <p class="MsoNormal"><img id="Picture_x0020_1"
>src="mailbox:///home/user/.thunderbird/XXXXXXXX.default/Mail/Local%20Folders/Drafts?number=903024121&amp;header=quotebody&amp;part=1.2&amp;filename=image001.jpg"
>            alt="canon" border="0" height="96" width="169"><o:p></o:p></p>
>        <p class="MsoNormal"><i>Contact me for more information.<o:p></o:p></i></p>
>        <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
>      </div>
>    </blockquote>
>    <br>
>  </body>
></html>