30447 - Mail send fails silently

Status: VERIFIED WORKSFORME

(MailNews Core :: Backend, defect, P3)

Description

[Peter Trudelle]

Using today's verification build on Win98:
Open mail.
Compose plain text message.
Address to self (or any other account you can check)
Send.
Bogus HTML/plain text dialog appears.
Select plain text, OK.
Compose window disappears.
Message never arrives, appears to never have been sent, was not copied to IMAP 
Sent folder as specified.
No error messages appear.

Comment 1

[Peter Trudelle]

putting on smoketest regression blocker radar

Comment 2

[(not reading, please use [e-mail] instead)]

I'm investigating.

Comment 3

[esther]

Using build 2000-03-04-09 on win98, I can send and receive a plain text and html 
message using an IMAP test account.  I did just add this account to my profile. 

Comment 4

[Peter Trudelle]

I'm using an existing profile. By 'bogus', I'm referring to the very existence 
of the HTML/Plain text dialog while sending a plain text message.

Comment 5

[Jean-Francois Ducarroz]

Peter, are you using a HTML compose window (the formatting toolbar is present) 
to compose a plain text message. If yes, the problem you are seeing with the 
"bogus" dialog is bug 28420.

Comment 6

[Peter Trudelle]

Yes, I was.

Comment 7

[(not reading, please use [e-mail] instead)]

questions about your profiles:

did you have more than one?
(did you launch from the profile manager)
are the migrate profiles, or profiles you created within the application?

I'm pretty sure I saw this same failure when peter originally reported it, but
I'm not able to reproduce anymore.

Comment 8

[Peter Trudelle]

Yes, I have three profiles; two migrated, one created in the app.

Comment 9

[Peter Trudelle]

This seems to be working in today's NS comm verif build, using the same profile. 
 Since sspitzer thinks it may have behaved erratically for him too, I'm going to 
leave this open for now.  There may be some other factor involved, perhaps QA 
can investigate to determine proper resolution of this bug. 
One difference: after install, I used chofmann's workaround for bug <a 
href="http://bugzilla.mozilla.org/show_bug.cgi?id=30449"30449</a>.  Perhaps the 
same comm installer problem is responsible for this bug.

Comment 10

[(not reading, please use [e-mail] instead)]

I'm unable to reproduce.

I suggest marking this worksforme until someone can reproduce it again.

Comment 11

[Peter Trudelle]

Sure, as long as QA will check for a real problem hiding here.

Comment 12

[esther]

Update:  I still can't reproduce this.  I was working from home in my comment on 
3-4, using a 56k modem when I couldn't reproduce this.  I tried again with 
existing profiles and profiles with 3 accounts.  Couldn't reproduce it.  I tried 
again this morning from work downloading saturday's build 3-4-09.   I still 
can't reproduce this.  With this build the browser doesn't display, however it 
leaves an incident in the Tasks menu for each failed attempt.  So I tried this 
again, launching -mail and sending a message, after 3 failed launchings of the 
Browser (which left 3 mozilla incidents listed in the Tasks menu).  I still 
can't reproduce this.  Not sure how much more I can do, I'll talk to seth to see 
if he has anything more to add to reproducing this bug.

Comment 13

[(not reading, please use [e-mail] instead)]

I've got nothing to add.  marking worksforme.

Comment 14

[Peter Trudelle]

I can't reproduce it in builds since then either.  verifying wfm.  This type of 
failure is why I I've been trying to convince DP that the mail/news pre-checkin 
test should be 'Send a mail message, then read it', rather than "Send a message, 
Read a message".  Round trip counts for a lot more.