Close the compose window after a send results in a crash Talkback tracking ID: D4N00XXJ and D4N12SUI Release build from directory dated: 1999-04-30-08 Windows NT 4.0 1) Start apprunner 2) Tasks | Messenger 3) New Message 4) Address the message and enter a subject 5) Click Send. Message is sent 6) Compose window is still open (due to another bug that the compose window doesn't close after send) 7) Close the compose window 8) Crash occurs. I have to go and try this on Linux and Mac and will have results shortly. Until I find out the results, I cannot say whether this occurs on all platforms or not.

set target milestone to M5. Does anyone see this? Also, the prefs50.js file I used only has one POP account in it so I took out any factors of having more than one account.

same for me on Mac, with a today fresh build

Changing platform to ALL since this occurs on Mac and Win32 so far. I have to try Linux next.

This is the stack I get nsCaret::GetViewForRendering(nsPoint & {x=435 y=345}, nsIView * & 0x00000000) line 431 + 17 bytes nsCaret::DrawCaret() line 516 nsCaret::CaretBlinkCallback(nsITimer * 0x042d25d0, void * 0x042a9f60) line 577 TimerImpl::Fire(unsigned long 16924421) line 308 + 17 bytes TimerImpl::ProcessTimeouts(unsigned long 16924421) line 187 FireTimeout(HWND__ * 0x00000000, unsigned int 275, unsigned int 30520, unsigned long 16924421) line 101 + 9 bytes USER32! 77e7128c() nsAppShellService::Run(nsAppShellService * const 0x01011950) line 187 main(int 6, char * * 0x00fe1750) line 447 + 12 bytes mainCRTStartup() line 338 + 17 bytes It crashes on theView->GetPosition(&x, &y); where the View is pointing to a destroyed vtable. It looks like a timer needs to be killed before the view goes away. I'm cc'ing sfraser since it looks like he might be the owner of the file nsCaret.cpp. Any ideas Simon?

This is almost certainly a dup of bug 3914, which in turn was caused by bug 4127. After the leak fix checkins last night, things have changed now, and the caret should be being freed properly. If the pres shell is being freed, then the caret will take care of itself. If you guys have leaks that cause the pres shell to be leaked, then you will see this crash. Note that some new problems have showed up when closing the editor window, after the leak fixes (bug 5796). We're working on those.

Can we reproduce this problem without sending the message? If not, It might have something to do with the send code! I cannot test it right know because am rebuilding the project on my both machines...

I crash when just opening a compose window and closing a compose window. I don't need to send a message.

See bug 5796 that sfraser references. This appears to be an editor problem. The only thing that sfraser says that perhaps you guys should check out may be: "If you guys have leaks that cause the pres shell to be leaked, then you will see this crash" Just a thought.

On April 30 PowerPC build (1999043009) I crash when just opening a compose window and closing a compose window. I don't need to send a message.

A temporary fix for the editor close window crash follows: Index: nsTextEditor.cpp =================================================================== RCS file: /cvsroot/mozilla/editor/base/nsTextEditor.cpp,v retrieving revision 1.61 diff -r1.61 nsTextEditor.cpp 137c137 < }; --- > } 143c143 < }; --- > } 153a154,159 > > // this is a hack to have mTypeInState as a member variable, > // but still be able to express the nsIDOMSelectionListener > // interface. This addref prevents anyone calling delete on the typeInState, > // which is bad. > mTypeInState.AddRef(); Try this.

Assuming I applied the patch correctly, it still crashes with the same stack.

Then it sounds like you are leaking the pres shell. Try a breakpoint on the pres shell desctuctor. If you don't hit this on closing the window, then life will still suck.

This is where my lack of raptor knowledge shows. Where's the pres shell?

layout/html/base/src/nsPresShell.cpp

I hit the nsPresShell destructor. I never hit the nsTextEditor destructor.

I worked with putterman on this one. It appears that the pres shell containing the blinking caret is never freed (there is > 1 pres shell per window), so it still crashes. Fixing this would seem to require a review of ownership issues throughout the mail/news code, and may be blocked by 5394.

This where I asked Jean-Francois to look at this since I'm not familiar with this code. There appear to be two webshell's getting created for the compose window (I guess one is for the window and one is to host Ender?). Anyway, only one of these are getting destroyed and it's not the one that has the caret that's causing the problem.

moving to m6

Doesn't make mail too user-friendly by leaving all the compose windows around since closing them causes a crash. It would be good to have this fixed for M5 since this behavior is a regression from Win32's M4 build. But, chofmann, I guess we have to ship M5 soon; thus, you've made this a M6 bug? I'll update the release note bug to comment about this item then.

ducarroz doesn't have any quick fixes for this right now and he is working on the Mac startup crash.

Looks like bug 5870 fixed recently by the Ender team may have fixed this. putterman and ducarroz have verified in a very recent debug build on Win32 and Mac.

Using released build 1999050317 on win95 this is fixed. Stacey states it's fixed on linux 1999050317 build too. Waiting for Mac to be verified.

Peter just verified this on both netscape and mozilla mac 5/3 builds. This appears to be fixed when 5870 was fixed. Will resolve as fixed and verified per lchiang.

Since this bug was actually fixed in M5 and not M6, I'm correcting the target milestone.

clear the status.