Closed Bug 14727 Opened 21 years ago Closed 20 years ago

[PERF] Pages with forms degrade browser performance.


(Core :: Layout: Form Controls, defect, P3)






(Reporter: cpratt, Assigned: buster)



(Whiteboard: [Perf])

Build ID: 1999092308
Platform: Windows NT, Linux

To reproduce:
- Launch apprunner
- Go to
- 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.
Summary: Quitting app after capturing form hangs app → [PERF] Quitting app after capturing form hangs app
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.
Summary: [PERF] Quitting app after capturing form hangs app → [PERF] Pages with forms degrade browser performance.
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

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
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()
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?
Target Milestone: M11
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...
Assignee: morse → rpotts
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.
Whiteboard: [Perf]
Assignee: rpotts → buster
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
Depends on: 13374
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
*** Bug 12158 has been marked as a duplicate of this bug. ***
Target Milestone: M11 → M12
Blocks: 16654
Blocks: 17432
Closed: 20 years ago
Component: Single Signon → HTML Form Controls
Resolution: --- → FIXED
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
No longer blocks: 17432
You need to log in before you can comment on or make changes to this bug.