1218033 - [e10s] Leak when quitting immediately after using WebSockets

Status: NEW

(Core :: DOM: Core & HTML, defect, P3)

Description

[Blake Kaplan (:mrbkap) (inactive)]

Attachment: 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.

Comment 1

[Andrew McCreight [:mccr8]]

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.

Comment 2

[Olli Pettay [:smaug][[e-mail]]]

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())

Comment 3

[Jim Mathies [:jimm]]

Is this a serious enough issue to block e10s?

Comment 4

[Jason Duell]

> 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.

Comment 5

[Jim Mathies [:jimm]]

Ah I see, this is shutdown vs tab close. Not blocking.