Build ID: 1999092308 Platform: Windows NT, Linux To reproduce: - Launch apprunner - Go to http://people.netscape.com/morse/wallet/samples/INTERVIEW.HTML - Enter your first and last name - Select Edit | Wallet | Capture Form - Make your way through the ensuing dialogs - When finished with that, select File | Quit Result: The apprunner window goes away, but the DOS window remains (on Win32); Linux top shows the apprunner processes stick around for some time but eventually go away. Expected result: When you select Quit, the app should quit immediately. This might actually be a performance problem and not a freezing/hanging problem.

It's a performance problem. It can take up to two minutes or longer to quit the application when you've followed the steps outlined in this bug. During that period waiting for the app to quit, Windows lists it as 'not responding' and its open windows will not refresh / will look bad, etc.

This occurs whether or not you capture the form. In other words, do steps 1,2, and 6 (skipping 3, 4, and 5) and you get the same behavior. So the wallet/capture has nothing to do with this. Looks like the problem has to do with entering a page that displays a form. Once you do this, everything is sluggish for a while. I tried hitting the back button at this time and the browser hung for a long time before finally going back. Changing summary from "Quitting app after capturing form hangs app" to "pages with forms degrade browser performance". Copying karnaze on this.

Problem is that the EndDocumentLoadHandler is being fired over and over again. That handler is causing the code in nsWalletService.cpp to be reentered over and over again. Tracing back on the stack, I see that the OnStopRequest routine in nsDocLoader.cpp is being fired repeatedly. Below is the stack trace showing where that is being called from. I noticed that scc has made a change in nsDocLoader.cpp two days ago to "prevent re-entering the destructor". Well that certainly looks like what's happening here. So I'm copying scc on this. Scott, do you have any insights as to what is happening? nsDocLoaderImpl::FireOnEndDocumentLoad(nsDocLoaderImpl * 0x024ebd90, unsigned int 0) line 857 nsDocLoaderImpl::OnStopRequest(nsDocLoaderImpl * const 0x024ebd94, nsIChannel * 0x024e82e0, nsISupports * 0x00000000, unsigned int 0, const unsigned short * 0x00000000) line 747 nsLoadGroup::RemoveChannel(nsLoadGroup * const 0x024ebd20, nsIChannel * 0x024e82e0, nsISupports * 0x00000000, unsigned int 0, const unsigned short * 0x00000000) line 597 + 39 bytes nsInputStreamChannel::OnStopRequest(nsInputStreamChannel * const 0x024e82e4, nsIChannel * 0x024e80d0, nsISupports * 0x00000000, unsigned int 0, const unsigned short * 0x00000000) line 331 nsOnStopRequestEvent::HandleEvent(nsOnStopRequestEvent * const 0x024ea9d0) line 269 nsStreamListenerEvent::HandlePLEvent(PLEvent * 0x024ea9d4) line 144 + 12 bytes PL_HandleEvent(PLEvent * 0x024ea9d4) line 541 + 10 bytes PL_ProcessPendingEvents(PLEventQueue * 0x00a99910) line 500 + 9 bytes _md_EventReceiverProc(HWND__ * 0x075a04ee, unsigned int 49345, unsigned int 0, long 11114768) line 970 + 9 bytes USER32! 77e71268() 00a

OK, tracing back still further, I see that the nsOnStopRequestEvent::HandleEvent() method in nsAsyncStreamListener.cpp is being repeatedly fired.

Copying Eric Pollmann on this since he was involved with implementing the OnEndDOcumentLoad notification. Any suggestions Eric?

Actually, I didn't have anything to do with OnEndDocumentLoad. I implemented OnFormSubmit notification. LXR's CVS blame seems to think that Nisheeth and Radha might know more about nsWebShell::OnEndDocumentLoad (along with the half dozen other people who touched it)

cc'ing rick potts, Since he is the master of DocLoader.

hey steve, welcome to the wonderful world of webshells!! Recently, *all* edit fields were changed from being native to being "tiny little composer windows"... This means that eachc one of those form input fields has its own webshell & document loader. Since each one of these little gems has a document loader, it fires notifications (such as start/enddocumentload) all the way up the webshell hierarchy!! This is what you are seeing... I think that this bug is a dup of some other bug about having to split up the webshell for performance, so these little things aren't so heavy weight...

From Rick's comments, it seems like he's on top of this and that this is probably a dup of some other bug. Assigning to him so he can mark it as a dup.

hey steve, I'm sure that this is a dup of some other bug that you have related to webshells and Form INPUT fields... -- rick

I've done all the reasonable optimizations in the editor and the text control itself. I can't do anything else about this until the webshell redesign is done.

*** Bug 12158 has been marked as a duplicate of this bug. ***

this was entirely a gfx text control performance problem, so setting the component to HTML Form Controls. It is now fixed. there are more improvements I'd like to make, but for the sake of this bug, I think we can mark it fixed.

this bug is fixed marking verified