browser : --------- using official 0.9.9 for Mac OS X release. description: ------------- the subject may look silly but here's what happened : i had 3 big messages to send. i prepared them by selecting "send later". then i connected to the net and selected "send unsent messages". but i got no feedback telling me that any message were being sent... so, i figured nothing was happening... and as i am a "stupid normal user" (grin), i selected again "send unsent messages" --> crash. well, that's two problems in fact : - no feedback to the user for telling him that her messages are being sent - crash on selecting "send unsent messages" instead of having some alert windows with a message "your messages are already being sent, you fool !" i cannot tell at the moment if this is reproducible as i *am* sending those bigh messages right now and then i must leave... sorry. stack trace : ------------- Date/Time: 2002-04-01 14:07:57 +0200 OS Version: 10.1.2 (Build 5P48) Command: Mozilla PID: 241 Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x0000002c Thread 0: #0 0x03c66680 in CutRow__9morkTableFP9nsIMdbEnvP9nsIMdbRow #1 0x03c66664 in CutRow__9morkTableFP9nsIMdbEnvP9nsIMdbRow #2 0x03ca33ac in RemoveHeaderFromDB__13nsMsgDatabaseFP8nsMsgHdr #3 0x03ca2fc4 in 0x3ca2fc4 #4 0x03baa16c in DeleteMessage__20nsMsgLocalMailFolderFP11nsISupportsP12nsIMsgW #5 0x03ba756c in DeleteMessages__20nsMsgLocalMailFolderFP16nsISupportsArrayP12n #6 0x03b29138 in DeleteCurrentMessage__14nsMsgSendLaterFv #7 0x03b27a48 in OnStopSending__21SendOperationListenerFPCcUiPCwP11nsIFileSpec #8 0x03b0dbc4 in NotifyListenerOnStopSending__19nsMsgComposeAndSendFPCcUiPCwP11 #9 0x03b0d210 in DoDeliveryExitProcessing__19nsMsgComposeAndSendFP6nsIURIUii #10 0x03b0d2a4 in DeliverAsMailExit__19nsMsgComposeAndSendFP6nsIURIUi #11 0x03b0b340 in SendDeliveryCallback__FP6nsIURIUi17nsMsgDeliveryTypeP11nsISupp #12 0x03b2ade8 in OnStopRunningUrl__21nsMsgDeliveryListenerFP6nsIURIUi #13 0x0362f8c8 in BroadcastChange__20nsUrlListenerManagerFP6nsIURI15nsUrlNotifyT #14 0x0362fa20 in OnStopRunningUrl__20nsUrlListenerManagerFP17nsIMsgMailNewsUrlU #15 0x03b6a728 in SetUrlState__16nsMsgMailNewsUrlFiUi #16 0x03b172a0 in ProcessProtocolState__14nsSmtpProtocolFP6nsIURIP14nsIInputStre #17 0x03b65fac in OnDataAvailable__13nsMsgProtocolFP10nsIRequestP11nsISupportsP1 #18 0x01cd1f40 in HandleEvent__22nsOnDataAvailableEventFv #19 0x01cdfae0 in HandlePLEvent__23nsARequestObserverEventFP7PLEvent #20 0x005f0db0 in PL_HandleEvent #21 0x005f0c1c in PL_ProcessPendingEvents #22 0x00596abc in ProcessPendingEvents__16nsEventQueueImplFv #23 0x0254388c in ProcessPLEventQueue__26nsMacNSPREventQueueHandlerFv #24 0x02543650 in RepeatAction__26nsMacNSPREventQueueHandlerFRC11EventRecord #25 0x01f70b14 in DoRepeaters__8RepeaterFRC11EventRecord #26 0x025578f8 in DispatchEvent__16nsMacMessagePumpFiP11EventRecord #27 0x025574d0 in DoMessagePump__16nsMacMessagePumpFv #28 0x02556e4c in Run__10nsAppShellFv #29 0x0250b28c in Run__17nsAppShellServiceFv #30 0x004c8bb4 in main1__FiPPcP11nsISupports #31 0x004c968c in main Thread 1: #0 0x7000497c in syscall #1 0x70557600 in BSD_waitevent #2 0x70554b80 in CarbonSelectThreadFunc #3 0x7002054c in _pthread_body Thread 2: #0 0x7003f4c8 in semaphore_wait_signal_trap #1 0x7003f2c8 in _pthread_cond_wait #2 0x705593ec in CarbonOperationThreadFunc #3 0x7002054c in _pthread_body Thread 3: #0 0x70044cf8 in semaphore_timedwait_signal_trap #1 0x70044cd8 in semaphore_timedwait_signal #2 0x7003f2b8 in _pthread_cond_wait #3 0x70283ea4 in TSWaitOnConditionTimedRelative #4 0x7027d748 in TSWaitOnSemaphoreCommon #5 0x702c2078 in TimerThread #6 0x7002054c in _pthread_body Thread 4: #0 0x7003f4c8 in semaphore_wait_signal_trap #1 0x7003f2c8 in _pthread_cond_wait #2 0x70250ab0 in TSWaitOnCondition #3 0x7027d730 in TSWaitOnSemaphoreCommon #4 0x70243d14 in AsyncFileThread #5 0x7002054c in _pthread_body Thread 5: #0 0x7003f4c8 in semaphore_wait_signal_trap #1 0x7003f2c8 in _pthread_cond_wait #2 0x7055b884 in CarbonInetOperThreadFunc #3 0x7002054c in _pthread_body Thread 6: #0 0x70000978 in mach_msg_overwrite_trap #1 0x70005a04 in mach_msg #2 0x7017bf98 in __CFRunLoopRun #3 0x701b7100 in CFRunLoopRunSpecific #4 0x7017b8e0 in CFRunLoopRunInMode #5 0x7061be08 in NotificationThread__21XIOAudioDeviceManagerPB0 #6 0x706141c0 in Entry__9CAPThreadPB0 #7 0x7002054c in _pthread_body Thread 7: #0 0x70000978 in mach_msg_overwrite_trap #1 0x70005a04 in mach_msg #2 0x70026a2c in _pthread_become_available #3 0x70026724 in pthread_exit #4 0x70020550 in _pthread_body PPC Thread State: srr0: 0x03c66680 srr1: 0x0200f030 vrsave: 0x00000000 xer: 0x20000020 lr: 0x03c66664 ctr: 0x03c688f0 mq: 0x00000000 r0: 0x03c66664 r1: 0xbfffec50 r2: 0x039bf000 r3: 0x00000000 r4: 0x00000001 r5: 0x03c6af04 r6: 0x00000062 r7: 0x00000190 r8: 0x04eb8af8 r9: 0x85e39ff0 r10: 0xe0c493d1 r11: 0x03bff038 r12: 0x039c06f0 r13: 0x00000000 r14: 0x00000036 r15: 0x0005d850 r16: 0x00000001 r17: 0x80160fa8 r18: 0x000586a8 r19: 0x00001707 r20: 0x00000000 r21: 0x0000001c r22: 0x70004234 r23: 0x700042c8 r24: 0x7016b0dc r25: 0x006bac3c r26: 0x8081ab5c r27: 0x40bc2000 r28: 0x00000000 r29: 0xbfffef00 r30: 0xe7560000 r31: 0x00000001 **********
We should not allow Send Unsent Messages if we're already sending unsent messages. JF, is it possible for you to prevent this? Looking at the code, I suppose we could set a flag in the messenger object that we're doing a send unsent and clear it when the send finishes, and then either disable or ignore subsequent send unsent messages requests.
Status: NEW → ASSIGNED
I didn't crash, but I did get multiple copies of the messages, some assertions, and no status/progress. Is it because the send process status messages don't work with an nsIMsgWindow?
I take it back - eventually, I did crash because the mMessage header in the nsMsgSendLater object had been deleted. I didn't realize the send was still going on, because there's no progress or status. So there's probably some sort of ref-counting problem. I also had the copy to the sent folder failing multiple times after the send succeeded.
Created attachment 77119 [details] [diff] [review] proposed fix to display progress and status for send later This patch makes it so we can display progress and status when sending unsent messages. This should help prevent people from doing this, and be helpful in general!
Bienvenu, thanks a lot for your quick response !
You're welcome - however, I don't know if I'll be allowed to check this in for Moz 1.0 or not. I'm trying to get permission.
David, your patch seems ok but that won't prevent the user to press twice send later! Why not adding a boolean in nsMessenger that you set to true in nsMessenger::SendUnsentMessages and then later set it back to false when finish (propably in the sendlater listener)?
JF, this bug fix will have two parts. I think displaying the status messages is the most important part, because it will help all users of this command and will also prevent real world users from crashing.
Comment on attachment 77119 [details] [diff] [review] proposed fix to display progress and status for send later R=ducarroz
Attachment #77119 - Flags: review+
Comment on attachment 77119 [details] [diff] [review] proposed fix to display progress and status for send later sr=sspitzer can you go to interCaps before you check in? sendUnsentMessages(), in the .idl and the .js
Attachment #77119 - Flags: superreview+
ok, thx, converted to intercaps in my tree.
Discussed in Mail News bug meeting. Decided to ADT2 and plus this bug.
Keywords: nsbeta1 → nsbeta1+
Target Milestone: --- → mozilla1.0
Adding feedback will make it unlikely for soemone to do this twice and it will benefit anyone who uses this feature. nominating adt1.0.0
I'm going to spin off a new bug for disabling this command while doing a send unsent messages. bug 135454 filed.
updating platform, os's to ALL.
Component: Mail Database → Networking - SMTP
OS: MacOS X → All
Hardware: Macintosh → All
adt1.0.0+ (on ADT's behalf) for checkin approval into 1.0.
Keywords: adt1.0.0 → adt1.0.0+
Comment on attachment 77119 [details] [diff] [review] proposed fix to display progress and status for send later a=asa (on behalf of drivers) for checkin to the 1.0 trunk
Attachment #77119 - Flags: approval+
fix checked in to display status messages during send unsent messages.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
Using Commercial trunk 2002-04-08-09-trunk NT 4.0 2002-04-08-08-trunk linux 2.2 2002-04-07-08-trunk mac 9.2.2 Mozilla trunk 2002040809 on OS 10.1.3 I see in the bottom frame of Messenger(3 pane window) the following: -Sending unsent mesgs (only see this if you were offline when did the send later) -Delivering mail -Mail sent successfully Tried sending unsent mesgs via file menu, or by going offline then going online and sending mesgs at the prompt or automatically and they all worked. I saw the 3 display mesgs each time. marking as verified for UI mesg. Tested both modern/classic. Crash hasn't been fixed but that will be fixed by bug 135454.
Status: RESOLVED → VERIFIED
*** Bug 81625 has been marked as a duplicate of this bug. ***
This fix was checked/approved for trunk on 4-4. We didn't branch for commercial until 4-10. So this fix should be in the current branch builds. Checked the following commercial branch builds: 2002042306 NT 4.0 2002042305 Mac 10.1.3 2002042308 linux 2.2 I see in the bottom frame of Messenger(3 pane window) the following: -Sending unsent mesgs (only see this if you were offline when did the send later) -Delivering mail -Mail sent successfully adding keyword verified1.0.0
You need to log in before you can comment on or make changes to this bug.