cpratt Reporter
	Description • 25 years ago

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.

	cpratt Reporter
	Comment 1 • 25 years ago

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.

	Stephen P. Morse
	Comment 2 • 25 years ago

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.

	Stephen P. Morse
	Comment 3 • 25 years ago

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

	Stephen P. Morse
	Comment 4 • 25 years ago

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

	Stephen P. Morse
	Comment 5 • 25 years ago

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

	Eric Pollmann
	Comment 6 • 25 years ago

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)

	Radha on family leave (not reading bugmail)
	Comment 7 • 25 years ago

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

	rpotts (gone)
	Comment 8 • 25 years ago

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...

	Stephen P. Morse
	Comment 9 • 25 years ago

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.

	rpotts (gone)
	Comment 10 • 25 years ago

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

	buster Assignee
	Comment 11 • 25 years ago

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.

	buster Assignee
	Comment 12 • 25 years ago

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

	buster Assignee
	Comment 13 • 25 years ago

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.

	Paul MacQuiddy
	Comment 14 • 25 years ago

this bug is fixed marking verified