Put some breakpoints in the destructor for the widget imp on your favorite platform. Run viewer, and immediately quit. Note the destructor is never called for any widget (the throbber is the only chrome that gets deleted, but it's not a widget). The root of this, I think, is that we leak the toplevel widget (the mWindow member of nsBrowserWindow), and thus all widgets under that because it holds references to them (the parent holds a list of all its children). This is the cause of my bug, 4883.

Troy -- Since kevin is out, can you take a look at this one? It's pretty serious.

The problem is that the web shell is being leaked. The pres context and the document are being released fine. It appears that the extra reference to the web shell is from a nsHttpUrlImpl object whose reference is never dropping to 0 and so it never releases its reference on the web shell Changing component to netlib so someone who understands that angle can investigate

Turns out there's already an open bug that we're leaking the web shell, and since that's the real problem here I'm marking this bug a DUP *** This bug has been marked as a duplicate of 4127 ***

reopening bug per conversation with troy

clearing resolution.

Putting on QA Blocker radar

taking this bug back over. Everything seems to be ok in viewer, but not in apprunner (at least with the chrome). I'll try a text widget in viewer (say our homepage maybe) and see if the dstr is still being called correctly.

accepting bug. cc'ing pierre, scc, and sfraser.

Works in viewer. Going to yahoo creates two text widgets in the content area. CLosing the window deletes them both. On apprunner, going to yahoo creates two new text widgets in the content area, closing the window deletes none of them.

after further review, this is probably caused by the fact that we are leaking every single frame in apprunner (probably because we leak the webshells). I've traced through the addref/release chain and I didn't find any leaks like I did yesterday in apprunner. I think everything is accounted for and would be properly released if the webshell/frames all went away as planned. Moving up to M5 like the bug scc has, bug won't mark this a duplicate yet.

i meant, "like i found yesterday in viewer"

scc and i have verified that when bug 4127 is fixed, this will be fixed as well. Marking as a dup of that bug. *** This bug has been marked as a duplicate of 4127 ***

Changing all Networking Library/Browser bugs to Networking-Core component for Browser. Occasionally, Bugzilla will burp and cause Verified bugs to reopen when I do this in a bulk change. If this happens, I will fix. ;-)

Bulk move of all Networking-Core (to be deleted component) bugs to new Networking component.