Open Bug 393898 Opened 17 years ago Updated 1 month ago

DOMWindow often doesn't go away when I close a window created with window.open() or showModalDialog()

Categories

(Core :: XUL, defect)

x86
macOS
defect

Tracking

()

People

(Reporter: jruderman, Unassigned)

References

(Depends on 1 open bug)

Details

(Keywords: memory-leak, testcase)

Attachments

(1 file, 1 obsolete file)

267 bytes, text/html
Details
Attached file testcase
Steps to reproduce:
1. Load the testcase in a debug build of Firefox.
2. Click the "open a modal dialog" button.
3. Press Cmd+W.
4. Wait for GC and look at "--DOMWINDOW" lines.
5. Repeat steps 2-4.

Result: --DOMWINDOW lines after step 5 usually show a larger final number of windows (after GC) than at step 4.

They're all freed when I quit, but I think something is holding on to them longer than desired...
They seem to be freed if I open and close a View-Source window as well.  (Testing on Linux, anyway.)

(Also, after doing the showModalDialog test, I was actually unable to quit on the Mac.)
Note that the thing with closing the view source window didn't show up under Mac.

I debugged the problem (and I should even have a screencast of the whole debugging process), and it looks like the problem is that nonBrowserWindowStartup needs a corresponding shutdown function now that we create a SanitizeListener in it (nonBrowserWindowDelayedStartup).
Blocks: 284437
Component: DOM → OS Integration
Product: Core → Firefox
QA Contact: general → os.integration
Thanks, dbaron!

Do you understand why opening and closing View Source causes the extra DOMWindows to be freed?  I'm just curious.

CCing mano because he wrote nonBrowserWindowStartup for bug 172017 and added the SanitizeListener thing to it in bug 284437.
Status: UNCONFIRMED → NEW
Ever confirmed: true
So I'm a bit less sure of my analysis -- I can't even reproduce the bug reliably in the minimal browser window case rather than the modal dialog case -- opening and closing new tabs a few times makes the leak go away, which makes it seem like it's just a case of cycle collection taking multiple iterations to collect the windows.
Is there an easy way for me to force extra cycle collections in order to find out?  (Maybe an extension?)

Is it considered a bug if this takes multiple cycle collections?  I can imagine it confusing someone watching domwindow counts (like me) or memory usage, but it's pretty far from being a memory leak.
So it seems my debugging found bug 342600; I attached a patch there, although I haven't verified that it fixes the bug.  I still don't understand how I hit it while debugging this, and I have a very thorough log of my whole session.
I understand why my debugging was wrong; I said "I'm looking for an nsGlobalWindow at the end of a path" and the proceeded to debug an interesting-looking path that had an nsGlobalWindow in the middle.  It pointed me to a real code problem purely by accident.
Assignee: nobody → jag
Component: OS Integration → XP Toolkit/Widgets
Product: Firefox → Core
QA Contact: os.integration → xptoolkit.widgets
Assignee: jag → nobody
Severity: normal → S3
Attachment #9386834 - Attachment is obsolete: true
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: