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

VERIFIED FIXED in M8

Status

MailNews Core
Composition
P1
critical
VERIFIED FIXED
19 years ago
10 years ago

People

(Reporter: Katsuhiko Momoi, Assigned: Jean-Francois Ducarroz)

Tracking

Trunk
x86
Windows NT

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

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

Comment 1

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

Updated

19 years ago
Priority: P3 → P1
(Reporter)

Comment 2

19 years ago
Reset priority to 1 since only Latin 1 mail send is working
and that's not good enough for international testing for send.
(Reporter)

Updated

19 years ago
Summary: When View | Character set menu is set in the Mail Composer window, mail fails to go out → When View | Character set menu is set in the Mail Composer window, Messenger crashes and mail fails to go out

Updated

19 years ago
Summary: When View | Character set menu is set in the Mail Composer window, Messenger crashes and mail fails to go out → Blocker - When View | Character set menu is set in the Mail Composer window, Messenger crashes and mail fails to go out

Comment 3

19 years ago
cc to ducarroz@netscape.com, rhp@netscape.com.
Did someone changed this part recently?
(Reporter)

Comment 4

19 years ago
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", "momoi8@polyglot.mcom.com");
user_pref("mail.identity.id1.wrap_column", 72);
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Updated

19 years ago
Assignee: nhotta → ducarroz

Comment 5

19 years ago
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 ducarroz@netscape.com.

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

19 years ago
apprunner freezes as opposed to a crash. It seems that Talkback is not started.
(Assignee)

Updated

19 years ago
Status: NEW → ASSIGNED
(Assignee)

Updated

19 years ago
Target Milestone: M8
(Assignee)

Comment 7

19 years ago
Ok, I will fix it asap...
(Assignee)

Comment 8

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

Comment 9

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

Updated

19 years ago
Summary: Blocker - When View | Character set menu is set in the Mail Composer window, Messenger crashes and mail fails to go out → Blocker - When View | Character set menu is set in the Mail Composer window, Messenger freezes on "send" and mail fails to go out
(Reporter)

Comment 10

19 years ago
Corrected teh summary line to better reflect the problem.

Comment 11

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

Updated

19 years ago
Summary: Blocker - When View | Character set menu is set in the Mail Composer window, Messenger freezes on "send" and mail fails to go out → [PP] Blocker - When View | Character set menu is set in the Mail Composer window, Messenger freezes on "send" and mail fails to go out

Comment 12

19 years ago
adding PP to summary
(Assignee)

Updated

19 years ago
Whiteboard: debugging...
(Assignee)

Comment 13

19 years ago
good news, I can reproduce the problem on my PC, I can start debugging now...
(Assignee)

Comment 14

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

Updated

19 years ago
Summary: [PP] Blocker - When View | Character set menu is set in the Mail Composer window, Messenger freezes on "send" and mail fails to go out → [PP] Blocker - Messenger freezes on "send" and mail fails to go out (when a mailbox has been selected and opened?)
(Reporter)

Comment 15

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

Comment 16

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

Comment 17

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

Comment 18

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

Updated

19 years ago
Whiteboard: debugging... → Investigating...
(Assignee)

Comment 19

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

Updated

19 years ago
Summary: [PP] Blocker - Messenger freezes on "send" and mail fails to go out (when a mailbox has been selected and opened?) → [PP] Blocker - Messenger freezes on "send" and mail fails to go out when an IMAP mailbox has been selected
(Reporter)

Comment 20

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

Comment 21

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

Comment 22

19 years ago
cc: IMAP developers

Comment 23

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

Updated

19 years ago
QA Contact: momoi → lchiang
(Reporter)

Comment 24

19 years ago
For now, I changed the component to Backend from Internationalization,
and QA contact to lchiang.
(Assignee)

Comment 25

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

Updated

19 years ago
Severity: blocker → critical
Summary: [PP] Blocker - Messenger freezes on "send" and mail fails to go out when an IMAP mailbox has been selected → [PP] Messenger freezes on "send" and mail fails to go out when an IMAP mailbox has been selected
(Reporter)

Comment 26

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

Comment 27

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

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

Comment 29

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

Comment 30

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

Comment 31

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

Comment 32

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

Comment 33

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

Updated

19 years ago
Whiteboard: Investigating... → seems to be a duplicate of bug #7426
(Reporter)

Comment 34

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

Comment 35

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

Comment 36

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

Comment 37

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

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

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

Updated

19 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → DUPLICATE
(Assignee)

Comment 40

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

Comment 41

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

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

Comment 43

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

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

Comment 45

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

Updated

19 years ago
Whiteboard: seems to be a duplicate of bug #7426 → it's a duplicate of bug #7426 but I have a workaround I would like to check in
(Assignee)

Comment 46

19 years ago
rhp has reviewed my workaround, I am waiting on choffmann for the approuval...
(Assignee)

Updated

19 years ago
Status: RESOLVED → REOPENED
Whiteboard: it's a duplicate of bug #7426 but I have a workaround I would like to check in
(Assignee)

Comment 47

19 years ago
I have check in my workaround after I get the approuval from chofmann.
(Assignee)

Updated

19 years ago
Status: REOPENED → RESOLVED
Last Resolved: 19 years ago19 years ago
Resolution: DUPLICATE → FIXED

Updated

19 years ago
QA Contact: lchiang → momoi

Comment 48

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

Updated

19 years ago
Component: Internationalization → Composition
QA Contact: momoi → fenella
(Reporter)

Comment 49

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

Updated

19 years ago
Status: RESOLVED → VERIFIED

Comment 50

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

Updated

18 years ago
Blocks: 15774
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.