Bugzilla

(In reply to Andrew McCreight [:mccr8] from comment #6)
> I looked at the CC logs that kael shared. All of the leaked windows, including the ones for YouTube, were being leaked via various FetchStreamReader, either directly (eg the inner window was the mGlobal of a FetchStreamReader) or indirectly (eg the window was being held alive via an event in the ELM of a window mGlobal of a FetchStreamReader).
> 
> The FetchStreamReader all had a refcount of 2. They all had one known reference, which was the mFetchStreamReader field of a ReadRequest.
> 
> Hopefully somebody who is more familiar with FetchStreamReader can figure out what the missing reference might be.

[FetchStreamReader is passed to nsIOutputStream::AsyncWait](https://searchfox.org/mozilla-central/rev/f53c09a22edc700ab1a9eaaf4da0f0dd9f11bff3/dom/fetch/FetchStreamReader.cpp#193), perhaps that's the culprit and somehow the stream is not being closed nor releasing the reference?

(In reply to Andrew McCreight [:mccr8] from comment #6)
> I looked at the CC logs that kael shared. All of the leaked windows, including the ones for YouTube, were being leaked via various FetchStreamReader, either directly (eg the inner window was the mGlobal of a FetchStreamReader) or indirectly (eg the window was being held alive via an event in the ELM of a window mGlobal of a FetchStreamReader).
> 
> The FetchStreamReader all had a refcount of 2. They all had one known reference, which was the mFetchStreamReader field of a ReadRequest.
> 
> Hopefully somebody who is more familiar with FetchStreamReader can figure out what the missing reference might be.

[FetchStreamReader is passed to nsIAsyncOutputStream::AsyncWait](https://searchfox.org/mozilla-central/rev/f53c09a22edc700ab1a9eaaf4da0f0dd9f11bff3/dom/fetch/FetchStreamReader.cpp#193), perhaps that's the culprit and somehow the stream is not being closed nor releasing the reference?