Closed Bug 571159 Opened 9 years ago Closed 9 years ago
Global Window with unknown-content-type dialog
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.3a5pre) Gecko/20100607 Minefield/3.7a5pre When I quit Firefox after loading the testcase, it leaks 5x nsDocument and 2x nsGlobalWindow. This happens consistently. This might explain one of the most frequent oranges, bug 538462.
It doesn't matter whether I click save, click cancel, or ignore the diaog and quit with it still up. It leaks every way.
Bug 538462 is not only one of the most frequent oranges, but also a difficult one to star, because you have to correlate the DOMWindow from the leak log with the ++DOMWindow from the mochitest log.
Any idea if this is Mac-only?
Happens on Linux64 too.
This seems to fix it for me.
Comment on attachment 453850 [details] [diff] [review] v1 so we are completely unhooking the cycle, right? r=sdwilsh
Attachment #453850 - Flags: review+
Shouldn't this cycle be detected by the cycle collector, without needing to break it manually in js?
(In reply to comment #7) > Shouldn't this cycle be detected by the cycle collector, without needing to > break it manually in js? No, it can't. nsUnknownContentTypeDialog.prototype has a property progressListener, which is an object that stores a pointer to the nsUnknownContentTypeDialog in a property helperAppDlg. The prototype will stay alive until we unload the module, which happens after the last cycle collection, as far as the cycle collector is concerned all these objects are alive until shutdown. IIRC we can't really run cycle collection after unloading modules, but even if we could it seems like a bad idea to keep this dialog alive after it has been closed, it's just unnecessary bloat. Storing objects with cycles on prototypes of components is a bad idea in general.
I tried checking in attachment 453850 [details] [diff] [review], but it caused test failures. nsUnkownContentTypeDialog uses a timer that uses a check for mDialog being null to decide whether we still need to show the dialog. So nulling out mDialog will cause it to be reshown when the timer fires next. This patch also fixes the leak and passes on try server.
Comment on attachment 455265 [details] [diff] [review] v2 You just moved code so I'm not going to nit pick style. r=sdwilsh
Attachment #455265 - Flags: review?(sdwilsh) → review+
I landed this for you: http://hg.mozilla.org/mozilla-central/rev/a8dd758e11f1
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b3
You need to log in before you can comment on or make changes to this bug.