crash opening item in drafts folder (local folders only)

VERIFIED FIXED in M14

Status

SeaMonkey
MailNews: Message Display
P3
major
VERIFIED FIXED
19 years ago
14 years ago

People

(Reporter: Dawn Endico, Assigned: Jean-Francois Ducarroz)

Tracking

({crash})

Trunk
All
Windows NT
crash

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [PDT+])

(Reporter)

Description

19 years ago
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?)
(Reporter)

Comment 1

19 years ago
oops, i was supposed to assign to putterman
Assignee: phil → putterman

Comment 2

19 years ago
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.
(Reporter)

Comment 3

19 years ago
ok, now i have to figure out how to debug on this machine or figure
out how to compile with talkback.

Comment 4

19 years ago
If you can download a release build and reproduce it, I think talkback should be 
enabled assuming we're still doing that.

Comment 5

19 years ago
Peter, can you reproduce?
Dawn-  are you using plain text or html compose?
QA Contact: lchiang → pmock
(Reporter)

Comment 6

19 years ago
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.
(Reporter)

Comment 7

19 years ago
the only talkback builds i know of are for the milestone
and m13 works for me
(Reporter)

Comment 8

19 years ago
ok, i got it to crash in talkback.

Comment 9

19 years ago
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)

Updated

19 years ago
Severity: normal → major
Keywords: beta1

Comment 10

19 years ago
[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+]

Comment 11

19 years ago
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?

Updated

19 years ago
Summary: crash opening item in drafts folder (local folders) → crash opening item in drafts folder (local folders only)

Comment 12

19 years ago
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?  
(Reporter)

Comment 13

19 years ago
Yes, as i noted before, I got this to crash for talkback on feb 18.

Comment 14

19 years ago
ok.  I'll keep trying then.  I've had no luck doing a search in talkback lately.  
It just spins forever.

Comment 15

19 years ago
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?

Comment 16

19 years ago
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?

Comment 17

19 years ago
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.

Comment 18

19 years ago
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.

Comment 19

19 years ago
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

Comment 20

19 years ago
Actually, JF has a better beat on the use of identities in the draft code. JF, 
any ideas?

- rhp
Assignee: rhp → ducarroz
(Assignee)

Comment 21

19 years ago
I am looking at it...
Status: NEW → ASSIGNED
Target Milestone: M14
(Assignee)

Comment 22

19 years ago
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
(Assignee)

Comment 23

19 years ago
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.
(Assignee)

Comment 24

19 years ago
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);
(Assignee)

Comment 25

19 years ago
r=alecf
Whiteboard: [PDT+]ETA: 2/29, fix in hand. → [PDT+]ETA: 2/29, fix in hand, waiting for approval.
(Assignee)

Comment 26

19 years ago
Fixed and checked in.
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED
Whiteboard: [PDT+]ETA: 2/29, fix in hand, waiting for approval. → [PDT+]

Comment 27

19 years ago
I'll verify this in tomorrow's builds.
QA Contact: pmock → lchiang
(Reporter)

Comment 28

19 years ago
I rebuilt from the tip on Windows NT after ducarroz checked in the patch and
this fixed my problem. Thanks!

Comment 29

19 years ago
verified on win32 2000-03-02-09-m15 commercial build.
Need to verify on Linux and Mac.

Comment 30

19 years ago
fenella - can you help to verify?
QA Contact: lchiang → fenella

Comment 31

19 years ago
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.