User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.11) Gecko/20070312 Firefox/1.5.0.11 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.11) Gecko/20070312 Firefox/1.5.0.11 When the javascript function window.open() is used to open a new popup (modal or modeless doesn't matter) memory is claimed to open the new window. When that window is close using the close or window.close() function the memory reserved for that windows is not released. Opening the same popup again results in firefox claiming even more memory. The only way to release the memory claimed by firefox is closing firefox fully. Reproducible: Always Steps to Reproduce: 1. Put this code in a webpage: <input type="button" onclick="window.open('http://www.mozilla.org', 'popup', 'width=400,height=200', false);" /> 2. Click the button and watch memory usage of firefox using the taskmanager. 3. Close the popup 4. repeat step 2 and 3 several times and you will see that memory used by firefox increasing 5. Close firefox (all windows/tabs) 6. Alle memory claimed by firefox is released Actual Results: As described firefox keeps claiming memory with every popup, but never (until firefox self exits) releases that memory. Expected Results: Memory claimed for opening the popup released or reused for new popups. This issue also occurs on firefox 2.0.3. I haven't tested it on Linux, but i guess the issue is focussed on the 'gecko' rendering component. As the memory is released by closing the firefox application I haven't filed this issue as critial, but normal as the impact is limited to memory usage.

After some more searching if found two other issues similair to mine. The issues ids are 333978 and 334225. Note that i can still use all the features of firefox/extentions. The only problem is the memory usage.

I definitely see the memory usage not being released, but I think that's expected as part of bfcache/caching of session history. Note that it doesn't go up indefinitely, just to a certain point, then it hovers around that point.

(In reply to comment #0) > Build Identifier: (snip) Windows NT 5.1; ... > 2. Click the button and watch memory usage of firefox using the taskmanager. > 4.(snip) memory used by firefox increasing To Dave Mertens : (Q1) Same questions as Bug 320915 Comment #42. (a."Momory Usage" column? How about "Virtual Memory Size"? and so on) (b.If "Momory Usage" column, what happens when config.trim_on_minimize=true?) (Q2) Same asking as 320915 Comment #28. (Extensions are used? Even when new-profile? and so on) Anyway, read thru Bug 320915 first, please.

Bug 320915 Comment #28. Sorry for spam.

Sorry for the late response, but I received this morning the first feedback on this issue. I guess other mails ended up in my spam box. Currently i'm using 2.0.0.5, but the problem still remains. Firefox keeps claiming memory for each window/popup opened, with releasing that memory when it's closed. I've tested it with and without extensions, but it didn't make any difference. Again, the memory is fully released when firefox is closed itself. About the questions on #3: Q1.A: Both Memory and Virtual Memory columns keep increasing. The memory usage goes a bit harder up. Q1.B: In my case, memory usage remains the same. No increase or decrease. Q2: With- or without extensions didn't make any difference. I also want to note that Opera and Safari (for windows, beta) doesn't suffer of this problem. If MSIE is vulnerable, i don't know. (i)Explorer is to much integrated into windows to only look for memory usage of iexplorer.exe. But that keeps steady. IE7 with tabs also didn't visiblebly take more memory. But the memory of other browser keep incresing and decreasing, as where firefox keeps claiming memory. I hope this is of help.

(Q3) What is Firefox's behavior on Virtual Memory Size in next test? Does Virtual Memory Size of Firefox increase rapidly/infinitely? 0. Set startup page to blank (to simplify test case) 1. Start Firefox, and load local HTML which has buttons for "window.open()" and "window.close()" for 10 windows (disabling of POP up blocker is required) => VM_1 2. Open 10 windows => VM_2_A, and close the opened 10 windows => VM_2_B 3. Open 10 windows => VM_3_A, and close the opened 10 windows => VM_3_B 4. Open 10 windows => VM_4_A, and close the opened 10 windows => VM_4_B 5. Repeat open/close of 10 windows several times, and watch VM size How about browser.sessionhistory.max_total_viewers=0 case?

I can replicate a memory leak in the popup blocker with Mozilla Firefox 3 beta 3. Try out the attached test case. When you run the attached test case, a whole bunch of memory is used by the 'pageReport' object which contains references to all of the popups which have been blocked. Because the size of the pageReport object is not limited, the pagereport object can use up a lot of memory. When you close the tab, the memory used by the popup blocker continues to be used. I believe that this leak is due to a circular reference between the popup blocker, the notification bar, the document, and the window.

Haven't tried to reproduce but this has apparently morphed into a trunk/Gecko 1.9 bug and is not going to get resolved for Gecko 1.8.x. Clearing dependency.

is there not a better component for this?

Not tested this myself - but if it still repros, it sounds bad.

I can still reproduce this with Mozilla Firefox 3.5 Preview (3.5b99). Memory usage rises when I click the "options" button in the example test case in comment #7, and it never goes back down after. If you run the test case enough times, you can make Firefox use arbitrary amounts of memory.

Please re-nom after the bug has been confirmed.

There does seem to be a leak, at least if you bash Firefox with this script. The explicit allocations started out as 26MB, were 268MB after running the inner loop once, and dropped to 49MB after "Minimize Memory Use". The round of the internal loop takes about 30 seconds of CPU time, later rounds take somewhat more. Results from more rounds are listed below. The Explicit Allocation total from memory use (in MB): Initial value: 26MB After Run After "Minimize Memory Use" One round: 268 49 Second round: 314 78 After third: 314 88 Tried ten additional rounds and Firefox crashed. https://crash-stats.mozilla.com/report/index/bp-5b26923f-a15a-40dc-9db6-335c12110902 Restarted Firefox and the web page automatically reloaded and executed. After Run After "Minimize Memory Use" Ten rounds: 415 112 20 rounds: 143 (Contents of about:memory is below) The script doesn't always crash quickly. My first long attempt used over an hour of CPU time, but that experiment didn't finish as I needed to reboot my system. The process was using around 3GB of memory at the end. (Note to self: If one round of a test works, don't assume the next experiment should be 1000 rounds, at least not without measuring CPU time.) User Agent: Mozilla/5.0 (Windows NT 5.2; WOW64; rv:9.0a1) Gecko/20110831 Firefox/9.0a1 Main Process Explicit Allocations 147.52 MB (100.0%) -- explicit ├───90.34 MB (61.24%) -- js │ ├──73.46 MB (49.80%) -- gc-heap-chunk-dirty-unused │ ├───9.99 MB (06.77%) -- compartment([System Principal], 0x4a6a000) │ │ ├──4.74 MB (03.21%) -- gc-heap │ │ │ ├──2.17 MB (01.47%) -- objects │ │ │ ├──1.51 MB (01.02%) -- shapes │ │ │ ├──1.00 MB (00.68%) -- arena-unused │ │ │ └──0.06 MB (00.04%) -- (4 omitted) │ │ ├──1.82 MB (01.23%) -- (9 omitted) │ │ ├──1.75 MB (01.19%) -- mjit-code │ │ └──1.68 MB (01.14%) -- scripts │ ├───1.94 MB (01.32%) -- compartment(https://crash-stats.mozilla.com/report/i...) │ │ ├──1.00 MB (00.68%) -- (8 omitted) │ │ └──0.94 MB (00.64%) -- gc-heap │ │ └──0.94 MB (00.64%) -- (6 omitted) │ ├───1.43 MB (00.97%) -- (7 omitted) │ ├───1.34 MB (00.91%) -- gc-heap-chunk-admin │ ├───1.11 MB (00.75%) -- compartment(https://bugzilla.mozilla.org/show_bug.cg...) │ │ └──1.11 MB (00.75%) -- (9 omitted) │ └───1.07 MB (00.73%) -- compartment(atoms) │ └──1.07 MB (00.73%) -- (3 omitted) ├───31.65 MB (21.45%) -- heap-unclassified ├───21.43 MB (14.53%) -- storage │ └──21.43 MB (14.53%) -- sqlite │ ├──16.49 MB (11.18%) -- urlclassifier3.sqlite │ │ ├──16.41 MB (11.13%) -- cache-used │ │ └───0.08 MB (00.05%) -- (2 omitted) │ ├───2.12 MB (01.43%) -- (11 omitted) │ ├───1.90 MB (01.29%) -- places.sqlite │ │ ├──1.63 MB (01.11%) -- cache-used [4] │ │ └──0.27 MB (00.18%) -- (2 omitted) │ └───0.92 MB (00.63%) -- other ├────1.75 MB (01.19%) -- layout │ ├──1.30 MB (00.88%) -- arenas │ └──0.45 MB (00.30%) -- (1 omitted) ├────1.02 MB (00.69%) -- dom ├────0.88 MB (00.60%) -- xpti-working-set └────0.44 MB (00.30%) -- (3 omitted) Other Measurements 0.00 MB -- gfx-d2d-surfacecache 0.00 MB -- gfx-d2d-surfacevram 0.00 MB -- gfx-surface-image 0.36 MB -- gfx-surface-win32 143.90 MB -- heap-allocated 241.20 MB -- heap-committed 2.52 MB -- heap-dirty 762.10 MB -- heap-unallocated 2 -- js-compartments-system 6 -- js-compartments-user 82.00 MB -- js-gc-heap 1.57 MB -- js-gc-heap-arena-unused 0.00 MB -- js-gc-heap-chunk-clean-unused 73.46 MB -- js-gc-heap-chunk-dirty-unused 91.50% -- js-gc-heap-unused-fraction 278.05 MB -- private 286.36 MB -- resident 1,076.38 MB -- vsize

73.46 MB (49.80%) -- gc-heap-chunk-dirty-unused This is general js heap fragmentation.

We're tracking something very similar in bug 668809, and that has more up to date information, duping forward.