Closed Bug 28349 Opened 25 years ago Closed 25 years ago

crash opening item in drafts folder (local folders only)

Categories

(SeaMonkey :: MailNews: Message Display, defect, P3)

Product:
SeaMonkey
Component:
MailNews: Message Display
Platform:
All
Windows NT
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: endico, Assigned: bugzilla)

Details

(Keywords: crash, Whiteboard: [PDT+]) 

From Bug Helper:
User-Agent: Mozilla/4.7 [en]C-AOLNSCP  (WinNT; U)
BuildID:    2000021715
double clicking on a message in the drafts folder causes a crash.
I'm not using a debug build so I don't have a stack trace. If you
can't reproduce let me know and i'll try harder.
Reproducible: Always
Steps to Reproduce:
1. drag a message to the draft folder
2. open draft folder
3. double click on item in the draft folder
Actual Results:  it crashed
Expected Results:  it shouldn't crash

(are you happy jan?)
oops, i was supposed to assign to putterman
Assignee: phil → putterman
ok.  I can't reproduce this.  If you can either get me a stack trace or file a 
talkback report on this, that would be helpful.
ok, now i have to figure out how to debug on this machine or figure
out how to compile with talkback.
If you can download a release build and reproduce it, I think talkback should be 
enabled assuming we're still doing that.
Peter, can you reproduce?
Dawn-  are you using plain text or html compose?
QA Contact: lchiang → pmock
The drafts folder is part of the "Local Folders" account and there
is no choice in the prefs to change or view the compose mode so i
am apparently doing the default. My mail account is set to do html
compose. The message in the drafts folder is text.

My attempt to recompile and debug failed miserably. I'm getting errors
about missing symbols in system dll's. I give up. This crashed for me
with today's commercial and mozilla daily builds as well as one i built
myself an hour ago.
the only talkback builds i know of are for the milestone
and m13 works for me
ok, i got it to crash in talkback.
I'm seeing a crash every time I open drafts if drafts folder is on local
folders.

I don't see any target milestone set ... don't know that this would be a great
thing to have existing in beta1.
Keywords: crash
Hardware: PC → All
Summary: crash opening item in drafts folder → crash opening item in drafts folder (local folders)
Severity: normal → major
Keywords: beta1
[PDT+] for beta.  We need a drafts folder to recover from other crashes.  Please
mark worksforme ASAP if this can't be reproduced.
Whiteboard: [PDT+]
This can be reproduced as per Laurel's last comments on Friday.  Note that this 
only occurs when the draft folder is set to the local folder.  The user can 
change the drafts folder location via Edit | Mail/News Account settings. 

Perhaps release note?
Summary: crash opening item in drafts folder (local folders) → crash opening item in drafts folder (local folders only)
I still can't reproduce this.  I move a message to my Drafts folder on Local 
Mail.  I open up the folder, select the message and double click and everything 
works just fine.

The Drafts folder is the only folder that will actually work like a drafts 
folder so setting a different folder to be the drafts folder shouldn't matter.

Does anyone have a talkback report so that I can see where the crash it?  
Yes, as i noted before, I got this to crash for talkback on feb 18.
ok.  I'll keep trying then.  I've had no luck doing a search in talkback lately.  
It just spins forever.
I downloaded today's build just to see if there was a difference between the 
commercial build and my build and there isn't.  I still don't crash.  I wonder 
if we have some other setting that is different?
If anyone can get endico's talkback trace I'd appreciate it. I'm having no luck 
connecting to the server.

Anyway, I will list the steps I'm following:

Copy a message to my Local Mail Draft's folder.  Open the folder. Double click 
on a message.

You guys are crashing and I'm getting a new compose window with the draft.  

I will try creating a new account and see if that is any different.  Laurel, I 
know you migrate you accounts.  Does migrating versus a new account make any 
difference in whether or not you crash? And, are you crashing when double 
clicking on a message or just when opening Drafts?
I'll try to reproduce this today.  Laurel is out today and Wednesday.
Still trying to access the talkback server - it just keeps going and going.
Here are the exact steps:  win32 2000-02-28-09-m15 commercial build

I used a new profile so we'd all have the same pref setting. Start with 
-ProfileWizard to create a new profile

1) Set up a new mail account.  I chose to set up a POP account
2) In mail, edit account settings
3) For the Copies and Folders setting under the POP account, change to store the 
drafts to your drafts folder on local folders
4) Create a new message from your POP account
5) Address it and type a subject and body
6) File | Save As | Draft
7) Close the compose window
8) Expand your Local Folders hierarchy in the thread pane
9) Select the Drafts folder
10) Select the msg in the folder. It'll display
11) Double-click
12) Crash occurs.

I had to create a new profile to do this.  When I create a new profile and then 
an imap account, when I copy a message from the imap account to the local drafts 
folder and then double click on that message, I get the following crash.  
Reassigning to rhp.

nsStreamConverter::GetIdentity(nsStreamConverter * const 0x044bd9d4, 
nsIMsgIdentity * * 0x044bbd9c) line 676 + 10 bytes
mime_bridge_create_draft_stream(nsIMimeEmitter * 0x00000000, nsStreamConverter * 
0x044bd9d0, nsIURI * 0x044bd934, int 6) line 1812 + 43 bytes
bridge_create_stream(nsIMimeEmitter * 0x00000000, nsStreamConverter * 
0x044bd9d0, nsIURI * 0x044bd934, int 6, unsigned int 14, nsIChannel * 
0x045041f0) line 79 + 21 bytes
nsStreamConverter::Init(nsStreamConverter * const 0x044bd9d0, nsIURI * 
0x044bd934, nsIStreamListener * 0x00000000, nsIChannel * 0x045079a0) line 563 + 
45 bytes
nsStreamConverter::AsyncConvertData(nsStreamConverter * const 0x044bd9d0, const 
unsigned short * 0x00000000, const unsigned short * 0x00000000, 
nsIStreamListener * 0x00000000, nsISupports * 0x045079a0) line 903 + 34 bytes
nsMsgDraft::ProcessDraftOrTemplateOperation(const unsigned short * 0x044bf080, 
int 6, nsIMsgIdentity * 0x00000000, nsIMessage * * 0x00000000) line 207 + 47 
bytes
nsMsgDraft::OpenDraftMsg(nsMsgDraft * const 0x044bdb70, const unsigned short * 
0x044bf080, nsIMessage * * 0x00000000, nsIMsgIdentity * 0x00000000, int 0) line 
248
nsMsgComposeService::OpenComposeWindow(nsMsgComposeService * const 0x03b23340, 
const unsigned short * 0x00000000, const unsigned short * 0x044bf080, int 6, int 
0, nsIMsgIdentity * 0x00000000) line 115 + 47 bytes
XPTC_InvokeByIndex(nsISupports * 0x03b23340, unsigned int 3, unsigned int 5, 
nsXPTCVariant * 0x0012c7b8) line 139
nsXPCWrappedNativeClass::CallWrappedMethod(JSContext * 0x03672700, 
nsXPCWrappedNative * 0x03b246f0, const XPCNativeMemberDescriptor * 0x03b24ad4, 
nsXPCWrappedNativeClass::CallMode CALL_METHOD, unsigned int 5, long * 
0x0268adb8, long * 0x0012c978) line 898 + 43 bytes
WrappedNative_CallMethod(JSContext * 0x03672700, JSObject * 0x02745540, unsigned 
int 5, long * 0x0268adb8, long * 0x0012c978) line 200 + 34 bytes
js_Invoke(JSContext * 0x03672700, unsigned int 5, unsigned int 0) line 665 + 26 
bytes
js_Interpret(JSContext * 0x03672700, long * 0x0012d264) line 2292 + 15 bytes
js_Invoke(JSContext * 0x03672700, unsigned int 2, unsigned int 0) line 681 + 13 
bytes
js_Interpret(JSContext * 0x03672700, long * 0x0012db0c) line 2292 + 15 bytes
js_Invoke(JSContext * 0x03672700, unsigned int 1, unsigned int 0) line 681 + 13 
bytes
js_Interpret(JSContext * 0x03672700, long * 0x0012e3b4) line 2292 + 15 bytes
js_Invoke(JSContext * 0x03672700, unsigned int 1, unsigned int 0) line 681 + 13 
bytes
js_Interpret(JSContext * 0x03672700, long * 0x0012ec5c) line 2292 + 15 bytes
js_Invoke(JSContext * 0x03672700, unsigned int 1, unsigned int 2) line 681 + 13 
bytes
js_InternalInvoke(JSContext * 0x03672700, JSObject * 0x02726c00, long 41053192, 
unsigned int 0, unsigned int 1, long * 0x0012ede8, long * 0x0012ed94) line 754 + 
19 bytes
JS_CallFunctionValue(JSContext * 0x03672700, JSObject * 0x02726c00, long 
41053192, unsigned int 1, long * 0x0012ede8, long * 0x0012ed94) line 2790 + 31 
bytes
nsJSContext::CallEventHandler(nsJSContext * const 0x033af1d0, void * 0x02726c00, 
void * 0x02726c08, unsigned int 1, void * 0x0012ede8, int * 0x0012ede4) line 562 
+ 33 bytes
nsJSEventListener::HandleEvent(nsIDOMEvent * 0x0451f6a4) line 128 + 57 bytes
nsEventListenerManager::HandleEventSubType(nsListenerStruct * 0x0451a1d0, 
nsIDOMEvent * 0x0451f6a4, unsigned int 4, unsigned int 2) line 697 + 19 bytes
nsEventListenerManager::HandleEvent(nsIPresContext * 0x036ac660, nsEvent * 
0x0012f6c4, nsIDOMEvent * * 0x0012f68c, unsigned int 2, nsEventStatus * 
0x0012f9d0) line 837 + 29 bytes
nsXULElement::HandleDOMEvent(nsXULElement * const 0x0451a7f0, nsIPresContext * 
0x036ac660, nsEvent * 0x0012f6c4, nsIDOMEvent * * 0x0012f68c, unsigned int 2, 
nsEventStatus * 0x0012f9d0) line 3079
nsXULElement::HandleDOMEvent(nsXULElement * const 0x0451a700, nsIPresContext * 
0x036ac660, nsEvent * 0x0012f6c4, nsIDOMEvent * * 0x0012f68c, unsigned int 2, 
nsEventStatus * 0x0012f9d0) line 3102 + 39 bytes
nsXULElement::HandleDOMEvent(nsXULElement * const 0x0451c770, nsIPresContext * 
0x036ac660, nsEvent * 0x0012f6c4, nsIDOMEvent * * 0x0012f68c, unsigned int 2, 
nsEventStatus * 0x0012f9d0) line 3102 + 39 bytes
nsXULElement::HandleDOMEvent(nsXULElement * const 0x0451df90, nsIPresContext * 
0x036ac660, nsEvent * 0x0012f6c4, nsIDOMEvent * * 0x0012f68c, unsigned int 1, 
nsEventStatus * 0x0012f9d0) line 3102 + 39 bytes
nsEventStateManager::CheckForAndDispatchClick(nsEventStateManager * const 
0x03968c20, nsIPresContext * 0x036ac660, nsMouseEvent * 0x0012fac4, 
nsEventStatus * 0x0012f9d0) line 1709 + 42 bytes
nsEventStateManager::PostHandleEvent(nsEventStateManager * const 0x03968c20, 
nsIPresContext * 0x036ac660, nsGUIEvent * 0x0012fac4, nsIFrame * 0x02812f94, 
nsEventStatus * 0x0012f9d0, nsIView * 0x03986990) line 892 + 24 bytes
PresShell::HandleEvent(PresShell * const 0x036ada74, nsIView * 0x03986990, 
nsGUIEvent * 0x0012fac4, nsEventStatus * 0x0012f9d0) line 2959 + 43 bytes
nsView::HandleEvent(nsView * const 0x03986990, nsGUIEvent * 0x0012fac4, unsigned 
int 8, nsEventStatus * 0x0012f9d0, int & 0) line 799
nsView::HandleEvent(nsView * const 0x036adf30, nsGUIEvent * 0x0012fac4, unsigned 
int 28, nsEventStatus * 0x0012f9d0, int & 0) line 784
nsViewManager2::DispatchEvent(nsViewManager2 * const 0x036ac240, nsGUIEvent * 
0x0012fac4, nsEventStatus * 0x0012f9d0) line 1216
HandleEvent(nsGUIEvent * 0x0012fac4) line 69
nsWindow::DispatchEvent(nsWindow * const 0x036ade14, nsGUIEvent * 0x0012fac4, 
nsEventStatus & nsEventStatus_eIgnore) line 493 + 10 bytes
nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012fac4) line 514
nsWindow::DispatchMouseEvent(unsigned int 301, nsPoint * 0x00000000 {x=??? 
y=???}) line 2957 + 21 bytes
ChildWindow::DispatchMouseEvent(unsigned int 301, nsPoint * 0x00000000 {x=??? 
y=???}) line 3175
nsWindow::ProcessMessage(unsigned int 514, unsigned int 0, long 6488331, long * 
0x0012fd60) line 2243 + 24 bytes
nsWindow::WindowProc(HWND__ * 0x013e135e, unsigned int 514, unsigned int 0, long 
6488331) line 671 + 27 bytes
USER32! 77e71820()
0063
Assignee: putterman → rhp
Actually, JF has a better beat on the use of identities in the draft code. JF, 
any ideas?

- rhp
Assignee: rhp → ducarroz
I am looking at it...
Status: NEW → ASSIGNED
Target Milestone: M14
We crash in nsStreamConverter::GetIdentity because we try to addreff a null 
pointer. This occurs because we have never called nsStreamConverter::SetIdentity  
before or because we set a null identity. Still looking...
Whiteboard: [PDT+] → [PDT+]ETA: 2/29
The reason the identity is null is because we don't have an identity for the 
local folders account. The fix consists to check the identity bofore trying to 
addreff it.

Index: nsStreamConverter.cpp
===================================================================
RCS file: /cvsroot/mozilla/mailnews/mime/src/nsStreamConverter.cpp,v
retrieving revision 1.45
diff -r1.45 nsStreamConverter.cpp
674a675,678
>   /*
>       We don't have an identity for the local folders account,
>     we will return null but it is not an error!
>   */
676c680,681
<       NS_ADDREF(*aIdentity);
---
>       if (*aIdentity)
>               NS_ADDREF(*aIdentity);
Whiteboard: [PDT+]ETA: 2/29 → [PDT+]ETA: 2/29, fix in hand.
Thanks to alecf, I change my fix for using the macro NS_IF_ADDREF:

Index: nsStreamConverter.cpp
===================================================================
RCS file: /cvsroot/mozilla/mailnews/mime/src/nsStreamConverter.cpp,v
retrieving revision 1.45
diff -r1.45 nsStreamConverter.cpp
674a675,678
>   /*
>       We don't have an identity for the local folders account,
>     we will return null but it is not an error!
>   */
676c680
<       NS_ADDREF(*aIdentity);
---
>       NS_IF_ADDREF(*aIdentity);
r=alecf
Whiteboard: [PDT+]ETA: 2/29, fix in hand. → [PDT+]ETA: 2/29, fix in hand, waiting for approval.
Fixed and checked in.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Whiteboard: [PDT+]ETA: 2/29, fix in hand, waiting for approval. → [PDT+]
I'll verify this in tomorrow's builds.
QA Contact: pmock → lchiang
I rebuilt from the tip on Windows NT after ducarroz checked in the patch and
this fixed my problem. Thanks!
verified on win32 2000-03-02-09-m15 commercial build.
Need to verify on Linux and Mac.
fenella - can you help to verify?
QA Contact: lchiang → fenella
I try the scenario in the original report and also Lisa's dated 2000-02-29. This
bug does not exist any more. However, the message does not display in Local
Folder. Bug 30370
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.