793364 - Make TCPSockets work with nsILoadGroups

Status: RESOLVED WONTFIX

(Core :: DOM: Networking, defect, P5)

Description

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

This bug is filed in response to bug 793106 comment 5, so it's somewhat speculative. If it's wrong, please do close it.

When using the TCPSocket API to open a connection, we should make sure that it is added to the appropriate nsILoadGroup. That both means that if the loadgroup is cancelled we should close the TCPSocket, and as long as the TCPSocket is open, we should keep the .activeCount on the loadgroup up by one.

Comment 1

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Is there currently anything ensuring that a TCPSocket is closed if the app navigates away from the page owning the TCPSocket? If not this might be a blocker.

Comment 2

[Andrew Sutherland [:asuth] (he/him)]

(In reply to Jonas Sicking (:sicking) from comment #1)
> Is there currently anything ensuring that a TCPSocket is closed if the app
> navigates away from the page owning the TCPSocket? If not this might be a
> blocker.

It listens for inner-window destroyed:
http://mxr.mozilla.org/mozilla-central/source/dom/network/src/TCPSocket.js#280

Comment 3

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

That might not happen when the user leaves the page though, if the page is put in bfcache.

Comment 4

[Andrew Sutherland [:asuth] (he/him)]

(In reply to Jonas Sicking (:sicking) from comment #3)
> That might not happen when the user leaves the page though, if the page is
> put in bfcache.

I don't think the e-mail app will actually have its docshell navigated anyplace else, so for blocker purposes, this may not matter then since termination of the e-mail app should happen either by its owning iframe being removed or its process crashing.  It does sound like it could matter if run in Firefox, assuming bfcache semantics are to suspend JS execution.  In that case, depending on how the suspension happens, I might guess that incoming data could either be processed (if it's just the window that stops inbound events) or dropped on the floor (if the whole compartment changes to just throw when things are invoked in it).

Comment 5

[Christian :Biesinger (don't email me, ping me on IRC)]

(In reply to Andrew Sutherland (:asuth) from comment #4)
> assuming bfcache semantics are to suspend JS execution. 

they are

> In that case, depending on how the suspension happens, I might guess that
> incoming data could either be processed (if it's just the window that stops
> inbound events) 

this is the case

Comment 6

[Christian :Biesinger (don't email me, ping me on IRC)]

load group support should be relatively simple - basically you need to implement the nsIRequest interface and add yourself to the load group when the connection starts, and remove yourself from it when the connection is finished. implementing suspend/resume is optional but make sure you throw if you don't implement it.

Comment 7

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1472046

Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.

Comment 8

[Hsin-Yi Tsai (she/her) [:hsinyi]]

[domcore-bugbash-triaged] Doing domcore random bug triage - won't fix.