Created attachment 8678399 [details] bloatlog STR: 1. Start Firefox. 2. Navigate to http://wstest.silverwind.io/ 3. Quit with CTRL+q (on Linux). Actual results (output): Leaked URLs: http://wstest.silverwind.io/ ws://wstest.silverwind.io/ Expected results: No leak. I'll attach the results of the bloatlog. mccr8 and I were having trouble generating CC logs, though. He said he'd investigate more on Monday.
There is a bunch of networking stuff involved that does not participate in cycle collection, so I'll have to try the DMD heap scanner. When I tried it locally, it seemed like there was no shutdown leak if I closed the tab before shutting down (while keeping another tab open so the content process wasn't killed off early), so it may just be some weird shutdown issue rather than a true leak.
Assuming WebSocket is a main thread one, closing the tab should end up executing http://mxr.mozilla.org/mozilla-central/source/dom/base/WebSocket.cpp?rev=49d87bbe0122#1384 So we explicitly close the connection. Perhaps when shutting down without closing tabs we end up breaking up the docshell tree too late so that DisconnectFromOwner() doesn't really help. (but Necko used to keep objects alive too long, that was the reason to add DisconnectFromOwner())
tracking-e10s: --- → +
Summary: [e10s] Leak quitting immediately after using WebSockets → [e10s] Leak when quitting immediately after using WebSockets
Is this a serious enough issue to block e10s?
> Is this a serious enough issue to block e10s? Do we block releases on shutdown leaks? I wouldn't think so (it shouldn't affect the user experience in any way), but I don't actually know.
Ah I see, this is shutdown vs tab close. Not blocking.
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.