9364 - [PP] Messenger freezes on "send" and mail fails to go out when an IMAP mailbox has been selected

Status: VERIFIED FIXED

(MailNews Core :: Composition, defect, P1)

Description

[Katsuhiko Momoi]

** Observed with 7/7/99 Win32 build **

When I set the Mail Composer's View | Character Set menu, mail fails to
go out. If I don't touch the menu, then mail goes out OK. But this means
that I cannot anything but Larin 1 mail. This is an International
Mail blocker bug.

Comment 1

[Katsuhiko Momoi]

There's something strange going on when I'm setting Character
Set menu in the composer. See this verbose output in the Prompot window:

+++++++++++++++++++++++++++++++++++++++++++++++++++++++
ComposeMessage from XUL
Created nsToolkitCore
calling HandleUrl
Compose: ComposeStartup
[type=0]
[format=0]
[originalMsg=undefined]
Created nsEditorShell
Created editorShell
### window.editorShell.wrapColumn exception text: Component returned failure c
e: 0x80004001 [nsIEditorShell.wrapColumn, {file: file:///D|/smonkey707m8/x86re
chrome/messengercompose/content/default/messengercompose.xul, line: 99}] - fai
d
editor initialized in PLAIN TEXT mode
Attaching to WebShellWindow[]
Reading file...
Reading file...Done

.Show

.Address

.Attachments

.Wrap Long Lines
SetDocumentCharacterSet('ISO-8859-1');
Western (ISO-8859-1)
SetDocumentCharacterSet('ISO-8859-2');
Central European (ISO-8859-2)
SetDocumentCharacterSet('ISO-8859-3');
Esperanto/Maltese (ISO-8859-3)
SetDocumentCharacterSet('ISO-8859-4');
Baltic (ISO-8859-4)
SetDocumentCharacterSet('ISO-8859-9');
Turkish (ISO-8859-9)
SetDocumentCharacterSet('ISO-8859-10');
Northern European (ISO-8859-10)
SetDocumentCharacterSet('ISO-8859-14');
Celtic (ISO-8859-14)
SetDocumentCharacterSet('ISO-8859-15');
New Western (ISO-8859-15)
SetDocumentCharacterSet('ISO-2022-JP');
Japanese (ISO-2022-JP)
SetDocumentCharacterSet('Big5');
Traditional Chinese (Big5)
SetDocumentCharacterSet('GB2312');
Simplified Chinese (GB2312)
SetDocumentCharacterSet('EUC-KR');
Korean (EUC-KR)
SetDocumentCharacterSet('UTF-8');
UTF-8
SetDocumentCharacterSet('UTF-7');
UTF-7
SetDocumentCharacterSet('KOI8-R');
Cyrillic (KOI8-R)
SetDocumentCharacterSet('KOI8-U');
Ukrainian (KOI8-U)
SetDocumentCharacterSet('ISO-8859-7');
Greek (ISO-8859-7)
SetDocumentCharacterSet('VISCII');
Vietnamese (VISCII)
SetDocumentCharacterSet('TIS-620');
Thai (TIS-620)
SetDocumentCharacterSet('ARMSCII-8');
Armenian (ARMSCII-8)
SetDocumentCharacterSet Callback!
ISO-2022-JP
SendMessage from XUL
GenericSendMessage from XUL
Looking for identity id1
Identity = [xpconnect wrapped nsIMsgIdentity]
Looking for identity id1

ComposeUnload from XUL
+++++++++++++++++++++++++++++++++++++++++++++++++++++++

This is when the whole apprunner freezes and has to be
re-started. Nothing goes out. Note the repititive Charset
settings in the output. All of that to finally set it to
ISO-2022-JP?

Comment 2

[Katsuhiko Momoi]

Reset priority to 1 since only Latin 1 mail send is working
and that's not good enough for international testing for send.

Comment 3

[nhottanscp]

cc to [e-mail], [e-mail].
Did someone changed this part recently?

Comment 4

[Katsuhiko Momoi]

Since it seems to be looking for id1, here's my id1 settings. These
settings are shared by all 4 accounts I use:

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
user_pref("mail.account.account1.identities", "id1");
user_pref("mail.account.account1.server", "server1");
user_pref("mail.account.account2.identities", "id1");
user_pref("mail.account.account2.server", "server2");
user_pref("mail.account.account3.identities", "id1");
user_pref("mail.account.account3.server", "server3");
user_pref("mail.account.account4.identities", "id1");
user_pref("mail.account.account4.server", "server4");
user_pref("mail.accountmanager.accounts",
"account1,account2,account3,account4");
user_pref("mail.identity.id1.compose_html", false);
user_pref("mail.identity.id1.fullName", "Kat Momoi");
user_pref("mail.identity.id1.organization", "Netscape.com");
user_pref("mail.identity.id1.smtp_name", "momoi8");
user_pref("mail.identity.id1.smtp_server", "polyglot.mcom.com");
user_pref("mail.identity.id1.useremail", "[e-mail]");
user_pref("mail.identity.id1.wrap_column", 72);
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Comment 5

[nhottanscp]

I think this is related to the recent change of nsMsgCompFields.
SetCharacterSet used to take char* but now PRUnichar*, we do not need
nsAutoCString(). There are many other places in the file using nsAutoCString(),
they need to be removed.
Reassigning to [e-mail].

In fact, this function used to take nsString so nsAutoCString() did make sense
since nsMsgCompFields used char*. But now it just need to pass charset to
nsMsgCompFields.
http://lxr.mozilla.org/seamonkey/source/mailnews/compose/src/nsMsgCompose.cpp
260 nsresult nsMsgCompose::SetDocumentCharset(const PRUnichar *charset)
261 {
262   // Set charset, this will be used for the MIME charset labeling.
263   m_compFields->SetCharacterSet(nsAutoCString(charset));
264
265   return NS_OK;
266 }

Comment 6

[msanz]

apprunner freezes as opposed to a crash. It seems that Talkback is not started.

Comment 7

[Jean-Francois Ducarroz]

Ok, I will fix it asap...

Comment 8

[Jean-Francois Ducarroz]

First, I cannot reproduce the problem on my Mac with a debug tree of this morning 7:30. I am currently rebuilding
Windows
in the hope I will be able to reproduce it.

Naoki, msgCompFields::SetCharacterSet() could either take a PRUnichar* or a const char*. In the case of
nsMsgCompose::SetDocumentCharset, I could use the PRUnichar one and avoid to do the conversion using
nsAutoCString. But
in any case I don't thing is the source of the current problem. Does the Character Set Name use non ascii characters?
the name
"ISO-2022-JP" is ascii and therefore, doing any conversion on it doesn't have any effect else than passing from 2-
bytes
representation to 1-byte.

What worry me here is all those SetDocumentCharacterSet outputs momoi reported. momoi did you select several
time the
menu or you have just selected Japanese?

Comment 9

[Katsuhiko Momoi]

Actually I only selected "View | Chaarcter Set", not even any
specific item. That's when I saw all the character sets being
set. Tnen when I selected ISO-2022-JP, I saw:

SetDocumentCharacterSet Callback!
ISO-2022-JP

Comment 10

[Katsuhiko Momoi]

Corrected teh summary line to better reflect the problem.

Comment 11

[nhottanscp]

Jean-Francois, it worked with my Macintosh build too. My windows build has a
problem and I am rebuilding it. I agree with you that nsAutoCString is not a
source of the problem, no data loss (charset names are all ascii), probably
it just does unnecessary conversions.

Comment 12

[lchiang]

adding PP to summary

Comment 13

[Jean-Francois Ducarroz]

good news, I can reproduce the problem on my PC, I can start debugging now...

Comment 14

[Jean-Francois Ducarroz]

The multiple output messages are generated by apprunner on Windows which dump the content (label and action) of a
menu when you select it. Totally normal!

I am working now on the send/crash part of the problem...

Comment 15

[Katsuhiko Momoi]

It looks like the Charset thing is bogus. It just looked that way.
I can reproduce this problem without changing the charset menu.
I don't have precise conditions, but it seems that when I have
a mailbox open (as opposed to no mailbox open when you just start
Messenger and go straight to creating a new mail msg window), the
freeze seems to happen. Also it seems to happen when more than
one addresses are entered in the address-to fields. However,
I did see this problem occur with only one address-to entry.

Still not sure of precise conditions, but I'm going to
change the summary a bit.

Comment 16

[Katsuhiko Momoi]

I have now been able to reproduce this problem 3 times in a row
when I tried to send a msg udner the condition in which a mailbox (Inbox)
is open and headers are showing but not message is selected for
display. This is under plain/text mail. No Character Set Menu
has been engaged. This looks like a reproducible problem now.

Comment 17

[Jean-Francois Ducarroz]

I need a procedure to reproduce the crash in order to be able to debug the
problem.

Previously when I say that I was able to reproduce the problem, it was in fact
only for the menu dump messages. I have never crashed and my message is always
send successfully.

Comment 18

[Katsuhiko Momoi]

Here's a set of steps which work for me.

1. Start Messenger: apprunner -mail
2. Double-click on an IMAP server icon and display mailbox folders
3. Pick out the Inbox folder and select it.
4. This will display all the headers in the thread pane.
5. Without selecting any message, now start a new Message window.
6. Input a single address into the addree-to field.
7. Write some strings into the Subject header and also the body.
8. Now click on the "Send" button.

The freeze occurs for me right after I do step 8 (under Windows NT4-J).
I haven't tested other language versions of Windows but expect this
to be a problem -- I'm not doing anything languge-specific in the steps
mentioned above.

Comment 19

[Jean-Francois Ducarroz]

When I follow momoi steps, Apprunner freeze during the send, the compose window
still open and I have the same debup output that him. I reproduce the problem
even without selecting a new char set. I don't have problem with a pop account.

Momoi, could you try to reproduce the problem with a pop3 account instance of a
imap one. Thanks.

Comment 20

[Katsuhiko Momoi]

jean-f, I tried 1) POP3 folder, 2) NNTP folder, and 3) 2 IMAP servers &
teh Inbox files. You're right. It's only when you I select IMAP mailbox
folders that Messenger freezes upon "send" - no charset menu change,
just a simple "send". With POP3 folders selected and thread pane
headers showing, the freeze problem does not occur upon "send".

I changed the summary line to reflect this condition.

Comment 21

[Katsuhiko Momoi]

I forgot to add that the problem does not occur when an NNTP folder
has been selected, either.

Comment 22

[lchiang]

cc: IMAP developers

Comment 23

[David :Bienvenu]

Do you have the preference set to do fcc? My guess would be no, but it's one
variable. I haven't had any problems sending mail with imap.

Comment 24

[Katsuhiko Momoi]

For now, I changed the component to Backend from Internationalization,
and QA contact to lchiang.

Comment 25

[Jean-Francois Ducarroz]

the freeze occurs when we try to close the compose window in
nsMsgCompose::CloseWindow(). Something must be corrupted in the window, very
stange. I will now try to understand what append in the web shell window when we
call close.

Comment 26

[Katsuhiko Momoi]

Downgraded to critical from blocker since for testing pruposes, we
have a few workarounds -- 1) don't select any server icons when
sending out msgs, 2) select POP3 mail server icons and mail folders.

This needs to be fixed for M8, however.

Comment 27

[Jean-Francois Ducarroz]

More info:

I freeze even without sending the message. Just do momoi's steps 1-5 and then
close manually the compose window. Apprunner freeze right away before the
window disapears.

Some time I crash even just by selecting my imap://inbox folder (step 1-3) with
the following stack trace:

_free_dbg_lk(void * 0x01cebc90, int 1) line 1033 + 60 bytes
_free_dbg(void * 0x01cebc90, int 1) line 970 + 13 bytes
operator delete(void * 0x01cebc90) line 49 + 16 bytes
nsVoidArray::~nsVoidArray() line 60 + 18 bytes
nsVoidArray::`scalar deleting destructor'(unsigned int 1) + 16 bytes
nsCellMap::~nsCellMap() line 60 + 30 bytes
nsCellMap::`scalar deleting destructor'(unsigned int 1) + 15 bytes
nsTableFrame::Reflow(nsTableFrame * const 0x01f35124, nsIPresContext & {...},
nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 0)
line 2520 + 46 bytes
nsTreeFrame::Reflow(nsTreeFrame * const 0x01f35124, nsIPresContext & {...},
nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 0)
line 286
nsContainerFrame::ReflowChild(nsIFrame * 0x01f35120, nsIPresContext & {...},
nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 0)
line 392 + 28 bytes
nsTableOuterFrame::IR_InnerTableReflow(nsTableOuterFrame * const 0x01f35230,
nsIPresContext & {...}, nsHTMLReflowMetrics & {...}, OuterTableReflowState &
{...}, unsigned int & 0) line 563 + 34 bytes
nsTableOuterFrame::IR_TargetIsInnerTableFrame(nsTableOuterFrame * const
0x01f35230, nsIPresContext & {...}, nsHTMLReflowMetrics & {...},
OuterTableReflowState & {...}, unsigned int & 0) line 355 + 31 bytes
nsTableOuterFrame::IR_TargetIsChild(nsTableOuterFrame * const 0x01f35230,
nsIPresContext & {...}, nsHTMLReflowMetrics & {...}, OuterTableReflowState &
{...}, unsigned int & 0, nsIFrame * 0x01f35120) line 327 + 31 bytes
nsTableOuterFrame::IncrementalReflow(nsTableOuterFrame * const 0x01f35230,
nsIPresContext & {...}, nsHTMLReflowMetrics & {...}, OuterTableReflowState &
{...}, unsigned int & 0) line 309 + 35 bytes
nsTableOuterFrame::Reflow(nsTableOuterFrame * const 0x01f35234, nsIPresContext &
{...}, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned
int & 0) line 960 + 35 bytes
nsBlockReflowContext::ReflowBlock(nsIFrame * 0x01f35230, const nsRect & {x=0 y=0
width=6495 height=1073741824}, int 0, int 0, int 1, nsMargin & {top=0 right=0
bottom=0 left=0}, unsigned int & 0) line 227 + 42 bytes
nsBlockFrame::ReflowBlockFrame(nsBlockReflowState & {...}, nsLineBox *
0x01f46e20, int * 0x0012ac80) line 2524 + 56 bytes
nsBlockFrame::ReflowLine(nsBlockReflowState & {...}, nsLineBox * 0x01f46e20, int
* 0x0012ac80) line 2014 + 20 bytes
nsBlockFrame::ReflowDirtyLines(nsBlockReflowState & {...}) line 1824 + 20 bytes
nsBlockFrame::Reflow(nsBlockFrame * const 0x01f35954, nsIPresContext & {...},
nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 0)
line 1199 + 18 bytes
nsBoxFrame::FlowChildAt(nsIFrame * 0x01f35950, nsIPresContext & {...},
nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 0,
int 1, nsIFrame * & 0x01f35950) line 711
nsBoxFrame::FlowChildAt(nsIFrame * 0x01f35950, nsIPresContext & {...},
nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 0,
int 1, nsIFrame * & 0x01f35950) line 685
nsBoxFrame::FlowChildren(nsIPresContext & {...}, nsHTMLReflowMetrics & {...},
const nsHTMLReflowState & {...}, unsigned int & 0, nsRect & {x=0 y=0 width=6495
height=0}, nsIFrame * & 0x01f35950) line 411
nsBoxFrame::Reflow(nsBoxFrame * const 0x00e9d82c, nsIPresContext & {...},
nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 0)
line 285
nsContainerFrame::ReflowChild(nsIFrame * 0x00e9d828, nsIPresContext & {...},
nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 0)
line 392 + 28 bytes
RootFrame::Reflow(RootFrame * const 0x01f2eb14, nsIPresContext & {...},
nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 0)
line 242
nsContainerFrame::ReflowChild(nsIFrame * 0x01f2eb10, nsIPresContext & {...},
nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 0)
line 392 + 28 bytes
ViewportFrame::Reflow(ViewportFrame * const 0x01f29ef4, nsIPresContext & {...},
nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 0)
line 440
nsHTMLReflowCommand::Dispatch(nsHTMLReflowCommand * const 0x0258aed0,
nsIPresContext & {...}, nsHTMLReflowMetrics & {...}, const nsSize & {width=6495
height=2640}, nsIRenderingContext & {...}) line 169
PresShell::ProcessReflowCommands(PresShell * const 0x01be41b0) line 1323
PresShell::ExitReflowLock(PresShell * const 0x01be41b0) line 702
PresShell::ContentRemoved(PresShell * const 0x01be41b8, nsIDocument *
0x01bbcc20, nsIContent * 0x01f2f8a0, nsIContent * 0x01ce4360, int 8) line 1776
XULDocumentImpl::ContentRemoved(XULDocumentImpl * const 0x01bbcc20, nsIContent *
0x01f2f8a0, nsIContent * 0x01ce4360, int 8) line 1983
RDFElementImpl::RemoveChildAt(RDFElementImpl * const 0x01f2f8a0, int 8, int 1)
line 1688
RDFGenericBuilderImpl::OnSetAttribute(RDFGenericBuilderImpl * const 0x01f30a3c,
nsIDOMElement * 0x01ce4350, const nsString & {"id"}, const nsString &
{"imap://qatest03@nsmail-2"}) line 1901 + 44 bytes
XULDocumentImpl::OnSetAttribute(XULDocumentImpl * const 0x01bbcc48,
nsIDOMElement * 0x01ce4350, const nsString & {"id"}, const nsString &
{"imap://qatest03@nsmail-2"}) line 3734
RDFElementImpl::SetAttribute(RDFElementImpl * const 0x01ce4350, const nsString &
{"id"}, const nsString & {"imap://qatest03@nsmail-2"}) line 916
ElementSetAttribute(JSContext * 0x01b97eb0, JSObject * 0x00e8c6e0, unsigned int
2, long * 0x00e995cc, long * 0x0012da74) line 258 + 23 bytes
js_Invoke(JSContext * 0x01b97eb0, unsigned int 2, int 0) line 655 + 26 bytes
js_Interpret(JSContext * 0x01b97eb0, long * 0x0012e2a0) line 2217 + 15 bytes
js_Invoke(JSContext * 0x01b97eb0, unsigned int 1, int 0) line 671 + 13 bytes
js_Interpret(JSContext * 0x01b97eb0, long * 0x0012ea88) line 2217 + 15 bytes
js_Invoke(JSContext * 0x01b97eb0, unsigned int 1, int 0) line 671 + 13 bytes
js_Interpret(JSContext * 0x01b97eb0, long * 0x0012f270) line 2217 + 15 bytes
js_Invoke(JSContext * 0x01b97eb0, unsigned int 1, int 0) line 671 + 13 bytes
js_InternalCall(JSContext * 0x01b97eb0, JSObject * 0x00e8cb18, long 15256352,
unsigned int 1, long * 0x0012f3b4, long * 0x0012f3bc) line 749 + 15 bytes
JS_CallFunctionValue(JSContext * 0x01b97eb0, JSObject * 0x00e8cb18, long
15256352, unsigned int 1, long * 0x0012f3b4, long * 0x0012f3bc) line 2643 + 29
bytes
nsJSEventListener::HandleEvent(nsIDOMEvent * 0x0258a9a0) line 97 + 34 bytes
nsEventListenerManager::HandleEvent(nsIPresContext & {...}, nsEvent *
0x0012f918, nsIDOMEvent * * 0x0012f8d4, unsigned int 2, nsEventStatus &
nsEventStatus_eConsumeDoDefault) line 586 + 21 bytes
RDFElementImpl::HandleDOMEvent(RDFElementImpl * const 0x01ca2da0, nsIPresContext
& {...}, nsEvent * 0x0012f918, nsIDOMEvent * * 0x0012f8d4, unsigned int 2,
nsEventStatus & nsEventStatus_eConsumeDoDefault) line 2351
RDFElementImpl::HandleDOMEvent(RDFElementImpl * const 0x01cac6a0, nsIPresContext
& {...}, nsEvent * 0x0012f918, nsIDOMEvent * * 0x0012f8d4, unsigned int 2,
nsEventStatus & nsEventStatus_eConsumeDoDefault) line 2354 + 39 bytes
RDFElementImpl::HandleDOMEvent(RDFElementImpl * const 0x01cb4d50, nsIPresContext
& {...}, nsEvent * 0x0012f918, nsIDOMEvent * * 0x0012f8d4, unsigned int 2,
nsEventStatus & nsEventStatus_eConsumeDoDefault) line 2354 + 39 bytes
RDFElementImpl::HandleDOMEvent(RDFElementImpl * const 0x01cb6fa0, nsIPresContext
& {...}, nsEvent * 0x0012f918, nsIDOMEvent * * 0x0012f8d4, unsigned int 2,
nsEventStatus & nsEventStatus_eConsumeDoDefault) line 2354 + 39 bytes
RDFElementImpl::HandleDOMEvent(RDFElementImpl * const 0x01cb67c0, nsIPresContext
& {...}, nsEvent * 0x0012f918, nsIDOMEvent * * 0x0012f8d4, unsigned int 2,
nsEventStatus & nsEventStatus_eConsumeDoDefault) line 2354 + 39 bytes
RDFElementImpl::HandleDOMEvent(RDFElementImpl * const 0x01ca28e0, nsIPresContext
& {...}, nsEvent * 0x0012f918, nsIDOMEvent * * 0x0012f8d4, unsigned int 2,
nsEventStatus & nsEventStatus_eConsumeDoDefault) line 2354 + 39 bytes
RDFElementImpl::HandleDOMEvent(RDFElementImpl * const 0x01cb8ec0, nsIPresContext
& {...}, nsEvent * 0x0012f918, nsIDOMEvent * * 0x0012f8d4, unsigned int 1,
nsEventStatus & nsEventStatus_eConsumeDoDefault) line 2354 + 39 bytes
nsEventStateManager::CheckForAndDispatchClick(nsEventStateManager * const
0x01cc5f70, nsIPresContext & {...}, nsMouseEvent * 0x0012fb90, nsEventStatus &
nsEventStatus_eConsumeDoDefault) line 671 + 31 bytes
nsEventStateManager::PostHandleEvent(nsEventStateManager * const 0x01cc5f70,
nsIPresContext & {...}, nsGUIEvent * 0x0012fb90, nsIFrame * 0x01cc48c0,
nsEventStatus & nsEventStatus_eConsumeDoDefault, nsIView * 0x01bb8d50) line 194
+ 24 bytes
PresShell::HandleEvent(PresShell * const 0x01bb85f4, nsIView * 0x01bb8d50,
nsGUIEvent * 0x0012fb90, nsEventStatus & nsEventStatus_eConsumeDoDefault) line
2125 + 43 bytes
nsView::HandleEvent(nsView * const 0x01bb8d50, nsGUIEvent * 0x0012fb90, unsigned
int 28, nsEventStatus & nsEventStatus_eConsumeDoDefault, int & 0) line 833
nsViewManager::DispatchEvent(nsViewManager * const 0x01bb8f70, nsGUIEvent *
0x0012fb90, nsEventStatus & nsEventStatus_eConsumeDoDefault) line 1736
HandleEvent(nsGUIEvent * 0x0012fb90) line 67
nsWindow::DispatchEvent(nsWindow * const 0x01bb8c24, nsGUIEvent * 0x0012fb90,
nsEventStatus & nsEventStatus_eIgnore) line 434 + 10 bytes
nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012fb90) line 455
nsWindow::DispatchMouseEvent(unsigned int 301, nsPoint * 0x00000000 {x=???
y=???}) line 3128 + 15 bytes
ChildWindow::DispatchMouseEvent(unsigned int 301, nsPoint * 0x00000000 {x=???
y=???}) line 3281
nsWindow::ProcessMessage(unsigned int 514, unsigned int 0, long 2687038, long *
0x0012fdb4) line 2407 + 24 bytes
nsWindow::WindowProc(HWND__ * 0x000303a6, unsigned int 514, unsigned int 0, long
2687038) line 503 + 27 bytes
USER32! 77e71250()
LIBREG32! _IMPORT_

Comment 28

[lchiang]

The part about crashing when just selecting the IMAP server are covered under:

http://bugzilla.mozilla.org/show_bug.cgi?id=9365
http://bugzilla.mozilla.org/show_bug.cgi?id=9398

Comment 29

[Jean-Francois Ducarroz]

this problem might be related some how to bugs http://bugzilla.mozilla.org/show_bug.cgi?id=9365

http://bugzilla.mozilla.org/show_bug.cgi?id=9398 .



I am still investigating...

Comment 30

[Jean-Francois Ducarroz]

I can reproduce the problem by opening the addressbook instance of a new
message. It seems that after you have selected an IMAP folder, if you open
another window, you will freeze when you try to close it.

Comment 31

[Jean-Francois Ducarroz]

the freeze occurs in nsWebShellWindow::Close()when trying to relase mWindow.

Comment 32

[Scott MacGregor]

JFD if this happens when an imap folder is selected then this may be a duplicate
or at least related to Bug #7426. How are you closing the window? by hitting the
'x' in the upper right corner or by choosing "Exit" from the menu?

Comment 33

[Jean-Francois Ducarroz]

I can also reproduce the problem by just closing the messenger 3 panes windows
by clicking the closebox after having selected my IMAP inbox folder. Therefore
nothing to do with message compose or addressbook.

Yes, mscott, it looks like to be a duplicate of Bug #7426. You cannot close any
window when an IMAP folder is selected.

Lisa, should I mark this bug a duplicated of bug #7426?

Comment 34

[Katsuhiko Momoi]

Assuming that this is a failure to close a window, does that also
explain the fact that mail does not get sent? I'm really more
concerned about this send failure.

Comment 35

[Jean-Francois Ducarroz]

momoi, the send operation is asynchronous. The close freeze apprunner before the
send is done that why the message is never send. Now I can change the code to
close the window when the send is really done, think I've planed to do for M9.
In fact we will just hide the window when the user clicks the send button and if
the send success, we will close it else we will show it again. But in any case
we will freeze at the end...

Comment 36

[Katsuhiko Momoi]

Has this problem been noted in the release notes for M7?
For the problem described in Bug 7426, you can at lease close
the Messenger window by selecting File/Exit, but once
you click on "send" button on the Compose window, even the "File/Exit"
does not work. Both the Compose and Messenger windows freeze.
I think for this part of the problem, there needs to be an
explicit instruction for avoidance.

Comment 37

[Katsuhiko Momoi]

Bug 7426 is targeted for M9. Knowing that the problem also affects
send operation under circumstances the users can fall into easily,
could we reconsider the target milestone? Scott?

Comment 38

[Scott MacGregor]

I'd rather not change the target fix for 7426. At this point, I have no idea
what's causing it yet and I believe it may "go away" when we land the new
networking model which effects imap heavily.

(In other words, we could change the bug to M8 but I don't think I'll be able to
come up with a solution in a reasonable amount of time and it may be a wasted
fix if the new networking model fixes the problem anyway)

Comment 39

[lchiang]

If you guys all agree that this is another manifestation of bug 7426, then go
ahead and mark as a duplicate.  However, I don't believe this was documented in
the M7 release notes because at that time, it was only thought that Suresh and I
had the problem.  Should we add information about this crash and the suggested
workaround in the M8 notes?

Comment 40

[Jean-Francois Ducarroz]

Lisa, yes, we should add information about this crash and especially the loss of
data (the message is never send) in the release note for M8.

I mark this bug as a duplicate of bug 7426.

*** This bug has been marked as a duplicate of 7426 ***

Comment 41

[Jean-Francois Ducarroz]

If you really don't want to loose data with this freeze, I can check in a new
version of nsMsgCompose that hide the window when the user click send and close
the window only after the send is done and good. With this version Apprunner
will freeze after the message has been send. Let me know if you want this in M8
else I will check it in a soon the tree open for M9

Comment 42

[Scott MacGregor]

I think we should consider taking this fix. JFD if you want, I'd be willing to
fly wing man for you on this. Send me a patch and I can review it and we can
take it to choffman to see if he feels we should take it.

Comment 43

[Katsuhiko Momoi]

jean-f, I like this a lot better. I think we are finding out
that there are other causes for freezing, but making the send
operation complete before closing the window could help in those
cases as well.
From a testing point of view, I would like the send ooperation to
be working even if I make a mistake to have selected an IMAP folder.
(We should recommend that the user not select an IMASP folder when
sending in the Release notes, however.)

If this is not too hard to do, I would love to see this in M8.

Comment 44

[lchiang]

There are a lot of M8 bugs out there so we might as well see if we can take a
fix for this (actually, really a workaround).  If chofmann allows the fix, we
need to reopen this bug and mark it fixed so that the fix will have a bug number
to go with it.  Leave  bug 7426 alone for now.

To clarify, will your fix, Jean-Francois, be for all platforms, under POP, IMAP,
and News, for plain text and html compose windows, and on new msgs and replies?

Comment 45

[Jean-Francois Ducarroz]

Yes, my workaround (as it isn't the fix to the freeze) affect any send operation
on all platform. It not a temporary feature but the final one, if it doesn't fit
in M8, it will be in M9.

Comment 46

[Jean-Francois Ducarroz]

rhp has reviewed my workaround, I am waiting on choffmann for the approuval...

Comment 47

[Jean-Francois Ducarroz]

I have check in my workaround after I get the approuval from chofmann.

Comment 48

[fenella]

Since the component is marked International, I have changed the QA contact
from lchiang to momoi.  Please this is a problem, please let me know.

Comment 49

[Katsuhiko Momoi]

Fenella, I'm sorry, I should have changed the component to Composition
or Backend as I said I would in my 7/7/99 comment. I must have neglected to
change the component after I made the comment. Can I ask you to
verify it since this has nothing to do with I18n?

Comment 50

[fenella]

Win_nt 4.0 (1999-08-16-09 M9)
Momoi, no problem, following the steps as you mentioned on 7/7/99, I do not see
the problem.  This bug has been fixed.