304853 - reply or reply all to news msg hangs if also Cc: or To: are not blank

Status: RESOLVED INCOMPLETE

(Thunderbird :: Message Compose Window, defect)

Description

[Marc A. Murison]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6

When replying (either Reply or Reply All) to a newsgroup message, TB 1.06 (also
1.02) will hang if you also are sending the message via SMTP (i.e., To: or Cc:
or Bcc: field(s) not empty).

Reproducible: Sometimes

Steps to Reproduce:
1. Click Reply or Reply All to a newsgroup message.
2. Make sure you are also sending the message via email (To: or Cc: or Bcc: ) in
addition to back to the newsgroup.
3. Type anything, or nothing, in the message body.
4. Send.

Actual Results:  
The client hangs, for all appearances looking as though it's taking forever to
send the message.  One must manually kill the message window.  It turns out that
the message is indeed posted to the newsgroup, but the email never goes out. 
Apparently there's a problem when sending a message to both NNTP and SMTP addresses.

Expected Results:  
Message should get posted to newsgroup as well as sent to specified email
address(es).

No crashes, just a hang.  Several colleagues, using various PC machines and
various recent versions of TB, are having the same problem.  Reproducibility is
maddening.  It appears that sometimes TB is in a mode where you just can't get
it to hang, while at other times it hangs on every single attempt.

I did a packet sniff using Ethereal and managed to catch the error as well as a
success for comparison.  Unfortunately the details are in two screen capture
images and I don't see any mechanism here for attachments.  On the off chance
that it might be helpful, here's a text description that goes along with the
images that went to our department head ("aa" is our local server):

 Well, I don't understand what's wrong still, but here are the traces of a
failure (top set of packets) and a success (bottom).  The first four packets
seem to be the same.  When Thunderbird hangs, it does so after sending packet 4.
 Packet 3 contains the message, which gets posted to the newsgroup.  This occurs
before the hang, so it doesn't matter what you do to Tbird after the hang, at
least for getting your message posted to the newsgroup.

Packet 5 on the failure did not get sent until I exited Tbird (the whole
program, not just the message edit window) 21 seconds later.  Packets 5-11 are
two attempts by Tbird to say hello to aa (91-byte packets with 37 bytes of
data), then an exit.  Notice the email did not get sent as Tbird just gave up
when the nntp negotiations failed; that's surely a Tbird bug (number 1).  On the
success case, aa had sent something back to Tbird (139-byte packet, 85 bytes of
data) after about 34 milliseconds, which made Tbird happy and to assume all was
well so it could get on with the email part.  On the failure side, Tbird hadn't
waited for aa to send that 85 bytes but immediately (less than 2 ms!) sent a
repeat of the 91-byte packet (bug number 2).  When aa sent the 85 bytes, Tbird
punted (RST = "reset") (bug number 3?). 

So the fault is definitely with Tbird.  To make matters worse, it's also
intermittent.  I somehow got Tbird into a 100% success mode and had to exit &
restart to get a failure.

Comment 1

[Marc A. Murison]

Attachment: screen captures of packet traces of NNTP+SMTP bug (top) and success (bottom).

Comment 2

[Mike Cowperthwaite]

Is this bug still an issue with TB 1.5?  I know I've seen a similar problem myself, and I believe there was a bug about it somewhere but I can't locate it at the moment.  Bug 319515 appears to be a dupe of this one.

Presumably the SMTP server seen in the packet trace was correct, but note that since 1.5 the SMTP server used by an identity, including News, is now explicitly displayed (and editable) in Account Settings.

Comment 3

[Joshua Cranmer [:jcranmer]]

Since there was no response to Mike's question over the intervening 1.5 years, I am assuming that either this bug has been fixed over the years or the problem does not rest with Thunderbird code. Resolving INCO.