Closed Bug 77254 Opened 24 years ago Closed 24 years ago

Compose window fails to send messages.

Categories

(MailNews Core :: Composition, defect, P1)

Product:
MailNews Core
Component:
Composition
Platform:
x86
Windows NT
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED DUPLICATE of bug 74387
Milestone:
mozilla0.9.1

People

(Reporter: skasinathan, Assigned: bugzilla)

References

Details

(Keywords: dataloss, regression, Whiteboard: [nsbeta1+])

Launch compose window and tried attaching (using File | attach web page OR from browser File | send page) www.yahoo.com. "sending of msg failed" alert pops up. Important note: I see this bug _only_ in my mozilla debug build from last night. I have done cvs diff of my entire tree and I don't have any changes in mailnews directory. Myself and sheelar tried on commercial release build and it works fine there. This may be related to bug 77053, but I don't see the dialog mentioned there ("There was a problem including the file %.200s in the message. Would you like to continue sending the message without this file?"). The console dumps the foll. Disabling View Source StyleSheet /mailnews/start.html Enabling Quirk StyleSheet Disabling Quirk StyleSheet WEBSHELL+ = 5 Disabling View Source StyleSheet WEBSHELL+ = 6 Disabling View Source StyleSheet Enabling Quirk StyleSheet Compose: ComposeStartup [nsIMsgIdentity: id2],[nsIMsgIdentity: id1] Registering plain text editor commands Registering HTML editor commands Have Find = true Have SpellChecker = false Disabling View Source StyleSheet blank Enabling Quirk StyleSheet replacing child in comp fields 2 recips Warning prev sibling is not in our list!!!set focus on the recipient WEBSHELL+ = 7 Disabling View Source StyleSheet /content/commonDialog.xul WEBSHELL- = 6 SendMessage from XUL GenericSendMessage from XUL Identity = [nsIMsgIdentity: id2] attachments = www.yahoo.com DetermineHTMLAction: preferFormat = 0, noHtmlRecipients are qatest37@netscape.com Comp fields attachment list = www.yahoo.com Counting REMOTE attachment 1 [details] [diff] [review]: www.yahoo.com Adding REMOTE attachment 0: www.yahoo.com Message Delivery Failed! WEBSHELL+ = 7 Disabling View Source StyleSheet /content/commonDialog.xul WEBSHELL- = 6 ###!!! ASSERTION: not-null m_mime_delivery_state: 'm_mime_delivery_state != nsnull', file D:\mozilla\mailnews\compose\src\nsMsgAtta ###!!! ASSERTION: not-null m_mime_delivery_state: 'm_mime_delivery_state != nsnull', file D:\mozilla\mailnews\compose\src\nsMsgAtta nsMsgComposeSendListener: the message send operation failed! RECEIVE ComposeProcessDone THE CLEANUP ROUTINE FOR nsMsgComposeAndSend() WAS CALLED ###!!! ASSERTION: NS_ENSURE_TRUE(msgWindow) failed: 'msgWindow', file D:\mozilla\mailnews\base\util\nsMsgProtocol.cpp, line 322 ###!!! ASSERTION: NS_ENSURE_TRUE(msgPrompt) failed: 'msgPrompt', file D:\mozilla\mailnews\base\util\nsMsgProtocol.cpp, line 288 ComposeUnload from XUL blank ###!!! ASSERTION: ~nsTextEditor: 'Not Reached', file D:\mozilla\editor\base\nsPlaintextEditor.cpp, line 169 /content/messengercompose/messengercompose.xul WEBSHELL- = 5 WEBSHELL- = 4 WEBSHELL+ = 5 Disabling View Source StyleSheet
change qa contact
QA Contact: esther → sheelar
This bug is hitting me hard. I can't forward any messages that include web pages. Every attempt eventually hits a timeout and gives the can't send message. In the meantime, the compose window sits there with the barber pole going and the status "Sending Message."
Keywords: nsdogfood, regression
To note, I am using 4/23 04 and I have attempted to use "Send Page" in addition to forwarding attached pages. Neither work. Those are in addition to the problem mentioned in this bug, but I believe them to all be the same problem.
After the timeout, I get this message: "An error occurred while sending mail. The mail server responded: dredd.mcom.com timing out connection to [208.12.41.247] 208.12.41.247. Please check the message and try again." Of course, trying again just leads you back to the same place...
I guess I didn't submit the comments I wrote earlier. marking nsbeta1+ and moving to mozilla0.9.1. JF or varada, could you look at this? If it's something we can reproduce and fix now then getting it into 0.9 would be great. I haven't had much luck reproducing this (though it did happen to me once though I was able to send the message on the second try). I haven't gotten then timeout error selmer is seeing.
Keywords: nsbeta1
Priority: -- → P1
Whiteboard: [nsbeta1+]
Target Milestone: --- → mozilla0.9.1
I was not able to reproduce this either with the debug build ( with Jf's latest patches for #77053-failing to send redirected pages) or with the regular release build of yesterday.
So I guess I lied to selmer when I said no one else is seeing this. It looks like 77281 and 77395 are similar or the same bug. So, others are seeing this.
*** Bug 77395 has been marked as a duplicate of this bug. ***
*** Bug 77281 has been marked as a duplicate of this bug. ***
I'm going to put this on the 0.9 radar so we can watch to see if a fix becomes available. I see the same thing as selmer, but I also can't exit the compose window. I have to kill with the task manager to get out of that session..
Summary: Fails to send web pages. → Compose window fails to send web pages.
Target Milestone: mozilla0.9.1 → mozilla0.9
Keywords: dataloss
if you can go to this bug in the browser, file | send page address the mail to me and selmer hit send and have the mail show up in my mail box, then I will by you a box of donuts.
I was able to Send Page on this bug page using Win32 2001-04-24-09-trunk build (commercial).
Would an SMTP log help in the cases of error? http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html
chofmann, just leave the compose window sitting there until the timeout happens. then you can close the window using the X button. Scott, I tried hitting send a second (and third) time on some of these and was never able to get it to send. (Gotta quit typing now, the page jumping all over is giving me a headache :-(
accepting
Status: NEW → ASSIGNED
Could everyone who experienced this problem verify if their SSL settings are off? We have a known problem with sending with SSL prefs turned on.
I did a bunch of testing the lat hour using a Mozilla debug from yesterday afternoon and I don't see a problem as long my ssl setting are off!
my plain text send bug got dupped on this one. I bet most people were like me: able to send small, test messages.
I have been testing for the last hour and have been able to send pages and reply to those messages without any problems. If not the SSL pref maybe you could try turning off the progress window to see if that is what is causing your problem. In prefs.js turn off this pref< user_pref("mailnews.show_send_progress", true);> change the true to false.
Ok, maybe some clues... maybe more noise... I just tried this a few more times. First time I crash just after the compose message came up. stack trace below.... Then a reboot Second time I sent successfully. --sent to e-mail chofmann@netscape.com Now I'm hung again. -"sending message" is displayed on the status bar after update to prefs.js After the time out on the second message the SMTP log for the two messages since reboot looks like C:\tmp>tail smtp.log 0[7b1ec0]: SMTP Send: DATA 0[7b1ec0]: SMTP entering state: 0 0[7b1ec0]: SMTP Response: 354 Ok Send data ending with <CRLF>.<CRLF> 0[7b1ec0]: SMTP entering state: 8 0[7b1ec0]: SMTP entering state: 9 0[7b1ec0]: SMTP Send: . 0[7b1ec0]: SMTP entering state: 0 0[7b1ec0]: SMTP Response: 421 dredd.mcom.com timing out connection to [208.12.37 .181] 208.12.37.181 0[7b1ec0]: SMTP entering state: 10 In reviewing the small differences in what I'm doing between the second message that worked and the third message that got the hang on I think I see the way to reproduce... the second message autocomplete showed me a list of drop downs and I choose "chofmann@netscape.com". In the the third message I quickly typed in "chofmann" and hit return without a fully qualified e-mail address appearing in the the to: field. That may be what sends me off in a spin for several minutes until the time out happend. When I went back into the address pane and completed the "@netscape.com" e-mail address the message was sent off. The work around seems to be make sure you have a fully qualified e-mail address, and the fix seems to be assume chofmann means chofmann@netscape.com or report these errors much faster and don't leave the compose window in a hung state for such a long period of time for this kind of error. Incident ID 29608636 Trigger Time 2001-04-25 10:37:27 Email Address chofmann@netscape.com User Comments send page (bug report) crashed just after the compose window came up and before I could get the address typed in. Build ID 2001042409 Product ID Netscape6.50 Platform ID Win32 Stack Trace Area::~Area [d:\builds\seamonkey\mozilla\layout\html\base\src\nsImageMap.cpp, line 101] Area::`scalar deleting destructor' nsTableOuterFrame::IR_InnerTableReflow [d:\builds\seamonkey\mozilla\layout\html\table\src\nsTableOuterFrame.cpp, line 1348] nsTableOuterFrame::IR_TargetIsInnerTableFrame [d:\builds\seamonkey\mozilla\layout\html\table\src\nsTableOuterFrame.cpp, line 1091] nsTableOuterFrame::IR_TargetIsChild [d:\builds\seamonkey\mozilla\layout\html\table\src\nsTableOuterFrame.cpp, line 1081] nsTableOuterFrame::IncrementalReflow [d:\builds\seamonkey\mozilla\layout\html\table\src\nsTableOuterFrame.cpp, line 1044] nsTableOuterFrame::Reflow [d:\builds\seamonkey\mozilla\layout\html\table\src\nsTableOuterFrame.cpp, line 1498] nsBlockReflowContext::DoReflowBlock [d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockReflowContext.cpp, line 569] nsBlockReflowContext::ReflowBlock [d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockReflowContext.cpp, line 339] nsBlockFrame::ReflowBlockFrame [d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 3951] nsBlockFrame::ReflowLine [d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 3218] nsBlockFrame::ReflowDirtyLines [d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 3021] nsBlockFrame::Reflow [d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 1772] nsBlockReflowContext::DoReflowBlock [d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockReflowContext.cpp, line 569] nsBlockReflowContext::ReflowBlock [d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockReflowContext.cpp, line 339] nsBlockFrame::ReflowBlockFrame [d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 3951] nsBlockFrame::ReflowLine [d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 3218] nsBlockFrame::ReflowDirtyLines [d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 3021] nsBlockFrame::Reflow [d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 1772] nsContainerFrame::ReflowChild [d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp, line 745] CanvasFrame::Reflow [d:\builds\seamonkey\mozilla\layout\html\base\src\nsHTMLFrame.cpp, line 324] nsBoxToBlockAdaptor::Reflow [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBoxToBlockAdaptor.cpp, line 869] nsBoxToBlockAdaptor::DoLayout [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBoxToBlockAdaptor.cpp, line 525] nsBox::Layout [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBox.cpp, line 985] nsScrollBoxFrame::DoLayout [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsScrollBoxFrame.cpp, line 377] nsBox::Layout [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBox.cpp, line 985] nsContainerBox::LayoutChildAt [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsContainerBox.cpp, line 595] nsGfxScrollFrameInner::LayoutBox [d:\builds\seamonkey\mozilla\layout\html\base\src\nsGfxScrollFrame.cpp, line 1039] nsGfxScrollFrameInner::Layout [d:\builds\seamonkey\mozilla\layout\html\base\src\nsGfxScrollFrame.cpp, line 1149] nsGfxScrollFrame::DoLayout [d:\builds\seamonkey\mozilla\layout\html\base\src\nsGfxScrollFrame.cpp, line 1047] nsBox::Layout [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBox.cpp, line 985] nsBoxFrame::Reflow [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBoxFrame.cpp, line 781] nsGfxScrollFrame::Reflow [d:\builds\seamonkey\mozilla\layout\html\base\src\nsGfxScrollFrame.cpp, line 738] nsContainerFrame::ReflowChild [d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp, line 745] ViewportFrame::Reflow [d:\builds\seamonkey\mozilla\layout\html\base\src\nsViewportFrame.cpp, line 538] nsHTMLReflowCommand::Dispatch [d:\builds\seamonkey\mozilla\layout\html\base\src\nsHTMLReflowCommand.cpp, line 145] PresShell::ProcessReflowCommand [d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 5605] PresShell::ProcessReflowCommands [d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 5660] PresShell::FlushPendingNotifications [d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 4638] nsEventStateManager::FlushPendingEvents [d:\builds\seamonkey\mozilla\content\events\src\nsEventStateManager.cpp, line 3468] nsEventStateManager::GenerateDragGesture [d:\builds\seamonkey\mozilla\content\events\src\nsEventStateManager.cpp, line 994] nsEventStateManager::PreHandleEvent [d:\builds\seamonkey\mozilla\content\events\src\nsEventStateManager.cpp, line 329] PresShell::HandleEventInternal [d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 5402] PresShell::HandleEvent [d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 5334] nsView::HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 377] nsView::HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 350] nsView::HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 350] nsViewManager::DispatchEvent [d:\builds\seamonkey\mozilla\view\src\nsViewManager.cpp, line 2055] HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 68] nsWindow::DispatchEvent [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 708] nsWindow::DispatchWindowEvent [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 725] nsWindow::DispatchMouseEvent [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 4030] ChildWindow::DispatchMouseEvent [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 4273] nsWindow::ProcessMessage [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 3038] nsWindow::WindowProc [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 960] KERNEL32.DLL + 0x363b (0xbff7363b) KERNEL32.DLL + 0x24407 (0xbff94407) 0x00688b5a
fyi: I've my SSL turned OFF and Progress window turned OFF. Basically I've all the default prefs. And one more important thing is I couldn't even send simple plain text message. So this may not be related to just web pages. (Changing summary). I can consistently duplicate this bug on my debug build. So feel free to use my system to debug this problem :)
Summary: Compose window fails to send web pages. → Compose window fails to send messages.
I am working from home today but I am sure Varada can go see Suresh... Right Varada?
I will work with suresh on his machine.
mvoing to 0.9.1. It seems we can correct this problem by creating a new profile, using it, and then going back to the old profile. We're not sure yet why this works or for how long it will keep working. For the moment it's a workaround. We'll keep looking into this and if more people see it, we'll have more test cases to help us figure out what's going on.
Target Milestone: mozilla0.9 → mozilla0.9.1
the attempt to create a new profile might be a red herring, at least for me... varada created a new profile on my system yesterday and I was able to send messages for a while. I can't send a very high pct. of messages again this morning..
just about every message I try to forward or any webpage I try to send that has an image in it gets the old hang-er-roni... my theory about the "chofmann" v. "chofmann@netscape.com" addressing also seems to be a red herring..
chofmann, I have a theory that this is related to the cache. When I moved my cache out of the way and created a new one, this started working for me again. Might be another red herring, but it's worth trying :-)
Could be. Removing my cache makes the problem go away for a while. I've been removing my cache very frequently for this problem and browser buster hang ups. I guess when mscott returns we might know more.
We found that chofmanm, selmer and kmurray have the SMTP SSL setting set to "When Available". Changing it to "Never" fix their problem. This is covered by bug 74387.
same for suresh. This is a dup of bug 74387 *** This bug has been marked as a duplicate of 74387 ***
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
Ducarroz is right. It works for me after I changed the _SMTP_ SSL setting. Initially I thought it was _incoming server_ SSL setting. :)
verified as dup
Status: RESOLVED → VERIFIED
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.