Closed Bug 138663 Opened 22 years ago Closed 22 years ago

Can't open composition window after sending mail (second compose window hangs/hung/broken)

Categories

(MailNews Core :: Composition, defect)

Product:
MailNews Core
Component:
Composition
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: Bienvenu, Assigned: jst)

References

Details

(Keywords: regression, smoketest)

Attachments

(2 files)

Proposed fix
4.32 KB, patch
harishd
: review+
jband_mozilla
: superreview+
Details | Diff | Splinter Review
Fix remaining problem when cache is full
1.52 KB, patch
bzbarsky
: review+
jst
: superreview+
Details | Diff | Splinter Review 
Steps to reproduce:

1. Compose and send a message to yourself
2. Click on a mail to: link, e.g., in a bugzilla message

the message composition window comes up blank, an error gets written to the
console, and you hit an assertion. After that, you can't bring up a composition
window until you shut down.

here's the console error:
************************************************************
* Call to xpconnect wrapped JSObject produced this error:  *
[Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [n
sIDOMXULElement.boxObject]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location
: "JS frame :: chrome://global/content/bindings/general.xml#editor.editorShell (
getter) :: onget :: line 0"  data: no]
************************************************************

Here's the assertion:
GlobalWindowImpl::GetPrivateRoot(GlobalWindowImpl * const 0x05e1bf00,
nsIDOMWindowInternal * * 0x0012b688) line 3728 + 38 bytes
GlobalWindowImpl::GetRootFocusController(GlobalWindowImpl * const 0x05e1bf00,
nsIFocusController * * 0x0012b6e4) line 3935 + 36 bytes
GlobalWindowImpl::Focus(GlobalWindowImpl * const 0x05e1beec) line 2364 + 40 bytes
XPTC_InvokeByIndex(nsISupports * 0x05e1beec, unsigned int 0x00000041, unsigned
int 0x00000000, nsXPTCVariant * 0x0012b874) line 106
XPCWrappedNative::CallMethod(XPCCallContext & {...}, XPCWrappedNative::CallMode
CALL_METHOD) line 2025 + 42 bytes
XPC_WN_CallMethod(JSContext * 0x0335c420, JSObject * 0x05c6c398, unsigned int
0x00000000, long * 0x0505d1dc, long * 0x0012bb24) line 1266 + 14 bytes
js_Invoke(JSContext * 0x0335c420, unsigned int 0x00000000, unsigned int
0x00000000) line 788 + 23 bytes
js_Interpret(JSContext * 0x0335c420, long * 0x0012c444) line 2745 + 15 bytes
js_Invoke(JSContext * 0x0335c420, unsigned int 0x00000001, unsigned int
0x00000002) line 805 + 13 bytes
nsXPCWrappedJSClass::CallMethod(nsXPCWrappedJSClass * const 0x06d27b70,
nsXPCWrappedJS * 0x06d27c20, unsigned short 0x0004, const nsXPTMethodInfo *
0x04224d08, nsXPTCMiniVariant * 0x0012c938) line 1193 + 21 bytes
nsXPCWrappedJS::CallMethod(nsXPCWrappedJS * const 0x06d27c20, unsigned short
0x0004, const nsXPTMethodInfo * 0x04224d08, nsXPTCMiniVariant * 0x0012c938) line 430
PrepareAndDispatch(nsXPTCStubBase * 0x06d27c20, unsigned int 0x00000004,
unsigned int * 0x0012c9e8, unsigned int * 0x0012c9d8) line 115 + 31 bytes
SharedStub() line 139
nsMsgComposeService::OpenWindow(const char * 0x00000000, nsIMsgComposeParams *
0x054ad598) line 267
nsMsgComposeService::OpenComposeWindowWithParams(nsMsgComposeService * const
0x0420ac50, const char * 0x00000000, nsIMsgComposeParams * 0x054ad598) line 622
nsMsgComposeService::OpenComposeWindowWithURI(nsMsgComposeService * const
0x0420ac50, const char * 0x00000000, nsIURI * 0x05c05104) line 539 + 25 bytes
nsMsgComposeContentHandler::HandleContent(nsMsgComposeContentHandler * const
0x0584bed8, const char * 0x0012d0c8, const char * 0x0240318c, nsISupports *
0x040b51d8, nsIRequest * 0x05da3360) line 78 + 34 bytes
nsURILoader::DispatchContent(nsURILoader * const 0x01cd85a0, const char *
0x0012d0c8, int 0x00000000, nsIRequest * 0x05da3360, nsISupports * 0x00000000,
nsIURIContentListener * 0x0408f460, nsISupports * 0x040b51d8, char * *
0x06d01320, nsIURIContentListener * * 0x0012d0a8, int * 0x0012d09c) line 806 +
49 bytes
nsDocumentOpenInfo::DispatchContent(nsIRequest * 0x05da3360, nsISupports *
0x00000000) line 298 + 148 bytes
nsDocumentOpenInfo::OnStartRequest(nsDocumentOpenInfo * const 0x05b67090,
nsIRequest * 0x05da3360, nsISupports * 0x00000000) line 227 + 16 bytes
nsMailtoChannel::AsyncOpen(nsMailtoChannel * const 0x05da3360, nsIStreamListener
* 0x05b67090, nsISupports * 0x00000000) line 388 + 20 bytes
nsDocumentOpenInfo::Open(nsIChannel * 0x05da3360, int 0x00000000, nsISupports *
0x040b51d8) line 169 + 18 bytes
nsURILoader::OpenURIVia(nsURILoader * const 0x01cd85a0, nsIChannel * 0x05da3360,
int 0x00000000, nsISupports * 0x040b51d8, unsigned int 0x00000000) line 537 + 20
bytes
nsURILoader::OpenURI(nsURILoader * const 0x01cd85a0, nsIChannel * 0x05da3360,
int 0x00000000, nsISupports * 0x040b51d8) line 499
nsDocShell::DoChannelLoad(nsIChannel * 0x05da3360, nsIURILoader * 0x01cd85a0)
line 5149 + 39 bytes
nsDocShell::DoURILoad(nsIURI * 0x05c05104, nsIURI * 0x00000000, nsISupports *
0x05debb88, nsIInputStream * 0x00000000, nsIInputStream * 0x00000000, int
0x00000001, nsIDocShell * * 0x00000000, nsIRequest * * 0x00000000) line 4924 +
38 bytes
nsDocShell::InternalLoad(nsDocShell * const 0x040b51d8, nsIURI * 0x05c05104,
nsIURI * 0x00000000, nsISupports * 0x00000000, int 0x00000001, const unsigned
short * 0x05907318, nsIInputStream * 0x00000000, nsIInputStream * 0x00000000,
unsigned int 0x00000001, nsISHEntry * 0x00000000, int 0x00000001, nsIDocShell *
* 0x00000000, nsIRequest * * 0x00000000) line 4717 + 51 bytes
nsDocShell::LoadURI(nsDocShell * const 0x040b51d8, nsIURI * 0x05c05104,
nsIDocShellLoadInfo * 0x05978700, unsigned int 0x00000000, int 0x00000001) line
662 + 73 bytes
nsDocShell::LoadURI(nsDocShell * const 0x040b51e8, const unsigned short *
0x0012d91c, unsigned int 0x00000000, nsIURI * 0x00000000, nsIInputStream *
0x00000000, nsIInputStream * 0x00000000) line 2398 + 38 bytes
nsMessenger::OpenURL(nsMessenger * const 0x041c5908, const char * 0x06caeef8)
line 599
XPTC_InvokeByIndex(nsISupports * 0x041c5908, unsigned int 0x0000000c, unsigned
int 0x00000001, nsXPTCVariant * 0x0012db2c) line 106
XPCWrappedNative::CallMethod(XPCCallContext & {...}, XPCWrappedNative::CallMode
CALL_METHOD) line 2025 + 42 bytes
XPC_WN_CallMethod(JSContext * 0x0335c420, JSObject * 0x03f679a0, unsigned int
0x00000001, long * 0x0505d1a0, long * 0x0012dddc) line 1266 + 14 bytes
js_Invoke(JSContext * 0x0335c420, unsigned int 0x00000001, unsigned int
0x00000000) line 788 + 23 bytes
js_Interpret(JSContext * 0x0335c420, long * 0x0012e6fc) line 2745 + 15 bytes
js_Invoke(JSContext * 0x0335c420, unsigned int 0x00000001, unsigned int
0x00000002) line 805 + 13 bytes
js_InternalInvoke(JSContext * 0x0335c420, JSObject * 0x05974300, long
0x03288438, unsigned int 0x00000000, unsigned int 0x00000001, long * 0x0012e95c,
long * 0x0012e82c) line 880 + 20 bytes
JS_CallFunctionValue(JSContext * 0x0335c420, JSObject * 0x05974300, long
0x03288438, unsigned int 0x00000001, long * 0x0012e95c, long * 0x0012e82c) line
3412 + 31 bytes
nsJSContext::CallEventHandler(nsJSContext * const 0x033e9268, void * 0x05974300,
void * 0x03288438, unsigned int 0x00000001, void * 0x0012e95c, int * 0x0012e960,
int 0x00000000) line 1016 + 33 bytes
nsJSEventListener::HandleEvent(nsJSEventListener * const 0x03459058, nsIDOMEvent
* 0x028ad650) line 182 + 77 bytes
nsEventListenerManager::HandleEventSubType(nsListenerStruct * 0x03459138,
nsIDOMEvent * 0x028ad650, nsIDOMEventTarget * 0x05016cf8, unsigned int
0x00000008, unsigned int 0x00000007) line 1250 + 20 bytes
nsEventListenerManager::HandleEvent(nsEventListenerManager * const 0x03458fe0,
nsIPresContext * 0x0322c970, nsEvent * 0x0012f4a4, nsIDOMEvent * * 0x0012f350,
nsIDOMEventTarget * 0x05016cf8, unsigned int 0x00000007, nsEventStatus *
0x0012f4f4) line 2245 + 36 bytes

I suspect it could be that the cached compose window is interacting poorly with
some box changes. Also, I believe cached compose window is turned off by default
on linux but this is easily reproducible on windows.
This was caused by bug 138138 which I just reopened, I'll fix this as part of
that bug...
Blocks: 138138
Status: NEW → ASSIGNED
*** Bug 138565 has been marked as a duplicate of this bug. ***
*** Bug 138696 has been marked as a duplicate of this bug. ***
Severity: normal → blocker
Keywords: regression, smoketest
is this trunk or branch? I can't tell by reading the bug.
My installs are all trunk 2002041903 on xp.  I'm seeing it in attempting to post
to newsgroups, File, Send Link in the browser, etc.
trunk. As a general rule, trunk, unless specified otherwise.
*** Bug 139307 has been marked as a duplicate of this bug. ***
clarifying summary -> this doesn't happen with just mailto links but the second
time you start compoesr
Summary: Can't open composition window via mailto link after sending mail → Can't open composition window after sending mail (second compose window hangs/hung/broken)
Same as bug 136952 ?
Yes, I believe--the same.
*** Bug 139422 has been marked as a duplicate of this bug. ***
*** Bug 136952 has been marked as a duplicate of this bug. ***
Copying over CC list, status whiteboard, and keywords from dupe bug 136952.
Keywords: mozilla1.0, nsbeta1+
Whiteboard: [adt2]
Removing bogus keywords and adt markings, this is trunk only.
Keywords: mozilla1.0, nsbeta1+
Whiteboard: [adt2]
This is a showstopper. I have to restart Mail after every message I compose;
even mailto links give me a hanging Compose window.
This is fixed in todays morning build. Fixed by the fix for bug 138138.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Johnny, this isn't fixed for me - I'm on the tip of the trunk, and this still
happens. I hate to reopen it, but I'm pretty sure it's still broken. Seth also
reports it's still broken with a trunk tree from this morning.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
yes, I still see this, win2k, from a tree I updated, clobbered and rebuilt this
morning.
Then why don't I see it in todays commercial nightly build?
The latest Trunk build (2002-04-23-10-trunk) still has the problem.
With 2002042303 on Win98 I see the original problem.  Note - the window title of
the blank compose window is the same as the subject for the message that was
previously sent.  However, a shut down is not required to allow a new
composition window to come up - you just need to go back in to mail and launch a
compose window from there.  Then mailto: will bring up a compose window.  
Ok, so now I do see this, hmm, odd. Investigating...
Ok, found the problem and talked to the sheriff. We decided to degrade this to a
critical bug so that we can get the tree opened, keeping the tree closed for
this isn't helping and I'm close to having a fix for this, so the fix will land
even if the tree is opened before the fix is done and checked in...
Severity: blocker → critical
Attached patch Proposed fix — — Splinter Review 
Make cached mail composed windows 'sticky' so that their presentation is not
thrown away when they're hidden...
Comment on attachment 80690 [details] [diff] [review]
Proposed fix

r=harishd
Attachment #80690 - Flags: review+
Comment on attachment 80690 [details] [diff] [review]
Proposed fix

sr=jband
Attachment #80690 - Flags: superreview+
Fix checked in.
Status: REOPENED → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → FIXED
The patch for nsMsgComposeService is not good enough. I would rather see the
stiky flag be set directly from inside the function ShowCachedComposeWindow,
that would be much cleaner and will prevent futur problem if somebody call
directly ShowCachedComposeWindow from somewhere else. Also you could clear the
sticky flag when we show the window.
This problem still exist when the cache if full and you close a window using the
oposite format than the currently cached window:

open an HTML compose window
close it
open a plain text compose window
close it
open a plain texe compose window
==> it will be broken!
Reopen as not all the cases are fixed (see my previous comment).
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
I haven't tested this patch yet as my tree need to be rebuilt but jst, feel
free to test it and check it in...
Comment on attachment 80708 [details] [diff] [review]
Fix remaining problem when cache is full

sr=jst
Attachment #80708 - Flags: superreview+
FYI, this bug also appears under Win98se.
Comment on attachment 80708 [details] [diff] [review]
Fix remaining problem when cache is full

r=bzbarsky, assuming jst has tested this....
Attachment #80708 - Flags: review+
Fix checked in.
Status: REOPENED → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → FIXED
Works fine. Thanks everybody...
*** Bug 139744 has been marked as a duplicate of this bug. ***
tested on 5/09, clicking on a mailto link opens the compose window, I can enter
and address, enter text, send and receive.
Status: RESOLVED → VERIFIED
Johnny, David B.,
N70PR1 is showing crashes at the GlobalWindowImpl::GetPrivateRoot signature. The
stack looks different from the stack originally posted in this bug. If it is the
same bug, can we get this fix in for RTM? Mozilla Trunk builds have no incidents
in the past ten days data, so we know the fix is good.

Stack trace(Frame) 

	 GlobalWindowImpl::GetPrivateRoot
[d:\builds\seamonkey\mozilla\dom\src\base\nsGlobalWindow.cpp  line 3628] 
	 GlobalWindowImpl::GetRootFocusController
[d:\builds\seamonkey\mozilla\dom\src\base\nsGlobalWindow.cpp  line 3814] 
	 nsDocShell::SetupNewViewer
[d:\builds\seamonkey\mozilla\docshell\base\nsDocShell.cpp  line 4231] 
	 nsDocShell::Embed
[d:\builds\seamonkey\mozilla\docshell\base\nsDocShell.cpp  line 3690] 
	 nsDocShell::CreateContentViewer
[d:\builds\seamonkey\mozilla\docshell\base\nsDocShell.cpp  line 4072] 
	 nsDSURIContentListener::DoContent
[d:\builds\seamonkey\mozilla\docshell\base\nsDSURIContentListener.cpp  line 108] 
	 nsDocumentOpenInfo::DispatchContent
[d:\builds\seamonkey\mozilla\uriloader\base\nsURILoader.cpp  line 364] 
	 nsDocumentOpenInfo::OnStartRequest
[d:\builds\seamonkey\mozilla\uriloader\base\nsURILoader.cpp  line 228] 
	 nsStreamIOChannel::OnStartRequest
[d:\builds\seamonkey\mozilla\netwerk\base\src\nsInputStreamChannel.cpp  line 474] 
	 nsOnStartRequestEvent::HandleEvent
[d:\builds\seamonkey\mozilla\netwerk\base\src\nsRequestObserverProxy.cpp  line 162] 
	 PL_HandleEvent
[d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c  line 597] 
	 PL_ProcessPendingEvents
[d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c  line 530] 
	 _md_EventReceiverProc
[d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c  line 1078] 
	 KERNEL32.DLL + 0x24407 (0xbff94407)  
	 0x006884d2   
 
     (6774102)	URL: www.uol.com.br
     (6722617)	Comments: Just tried to open application
     (6693702)	Comments: a popup asked if I wanted  Netscape 7.0 to be my default mail and
news page  before I could respond I was informed an illegal act had been
performed and asked to have the program shut down..    This has happened both
times I have tried to access news
     (6693702)	Comments:  program through Netscape  I fear I'm going to have to uninstall
this program. Am I doing something wrong? Please advise  thank you.
     (6672969)	Comments: I tried to run the Email service
     (6667782)	URL: www.pcwelt.de ... download try of Tweakui
     (6667782)	Comments: klicked on download
     (6664781)	Comments: trying to bring up news groups
     (6655074)	Comments: freeze when playing a Real Player media website.
     (6635755)	Comments: AOL is running and I just tried to open Netscape Mail & Newsgroups
Icon.
     (6621093)	Comments: trying to access newsgroups
     (6600981)	Comments: Turning it on.
I'm not sure this bug is related to the crash, since this bug never caused a
crash, and those comments don't look related to opening a second compose window.
Also, I'm not sure that Johnny's changes that caused this bug were ever checked
into the branch...in any case, Johnny will know better than I do.
The changes that caused this were *not* checked in on the branch. There is
however talk about taking those changes on the branch for MachV, so they might
land on the branch at some point...

IOW, please file a new bug on that crash...
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: