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

RESOLVED INACTIVE

Status

()

Core
XUL
RESOLVED INACTIVE
11 years ago
3 days ago

People

(Reporter: Jesse Ruderman, Unassigned)

Tracking

({memory-leak, testcase})

Trunk
x86
Mac OS X
memory-leak, testcase
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

11 years ago
Created attachment 278443 [details]
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
(Reporter)

Comment 3

11 years ago
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.
(Reporter)

Comment 5

11 years ago
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.
Depends on: 394514
Assignee: nobody → jag
Component: OS Integration → XP Toolkit/Widgets
Product: Firefox → Core
QA Contact: os.integration → xptoolkit.widgets

Updated

10 years ago
Assignee: jag → nobody

Comment 8

3 days ago
Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.
Status: NEW → RESOLVED
Last Resolved: 3 days ago
Resolution: --- → INACTIVE
You need to log in before you can comment on or make changes to this bug.