If this gets b+ I can take it.

I poked at this briefly, didn't quite figure the whole thing out, but made some progress: There's what looks like a cycle between nsDOMStorageDBWrapper (which doesn't use the MOZ_COUNT_CTOR/MOZ_COUNT_DTOR macros!), an nsTimerImpl that it owns, an nsDOMStorage that is observing the timer (so the timer owns it), and a DOMStorageImpl. Normally nsDOMStorageDBWrapper::StopTempTableFlushTimer destroys the timer but it never gets called. The two places it can get called from are nsDOMStorageDBWrapper's dtor which isn't going to happen since we have a cycle and when the timer fires at [1]. We never end up in UnflushedDataExists, so I assume the timer never fires, but that's where I quit debugging. [1] http://mxr.mozilla.org/mozilla-central/source/dom/src/storage/nsDOMStorage.cpp#444

That's an nsDOMStorageManager that is observing the timer.

Or maybe it's not a cycle there, it doesn't look like nsDOMStorageManager owns anything.

nsGlobalWindow leaks are uncool, Honza, or Kyle, please do have a closer look.

I've figured this one out. Patch in the morning.

Comment on attachment 503806 [details] [diff] [review] Pending storage events need to be cycle collected. So, the issue here is that pending storage events form a cycle with the nsGlobalWindow. This would not be an issue if we ever dispatched them, but in Jesse's testcase the window is never Unfrozen and the events are never fired. Thus, we need to cycle collect the nsDOMStorageEventArray.

Comment on attachment 503829 [details] [diff] [review] Pending storage events need to be cycle collected. This has a better test. I managed to get it down to just one setTimeout.