WebSockets connections initiated from service workers are not closed when the worker is unregistered

RESOLVED INVALID

Status

()

defect
RESOLVED INVALID
Last year
Last year

People

(Reporter: fabrice, Unassigned)

Tracking

(Blocks 2 bugs)

Firefox Tracking Flags

(Not tracked)

Details

Reporter

Description

Last year
I will try to provide a reduced test case, but what I am seeing is:
- creating a WS connection from a SW works just fine.
- when the SW is unregistered, the WS connection stays up, and is only closed when the process dies.

Verified in Fx 59. I'm happy to debug but I'm not sure where to look at first.
Component: DOM: Workers → DOM: Service Workers
Reporter

Comment 1

Last year
The process which need to die in comment #0 is the parent process, so it looks like the disappearance of the web socket is not properly remoted.

Here's what netstat shows after opening and unregistering twice this service worker:

tcp        0      0 localhost:50132         localhost:tproxy        ESTABLISHED 4935/firefox        
tcp        0      0 localhost:tproxy        localhost:39260         ESTABLISHED 30070/echo-ws-server    
tcp        0      0 localhost:39260         localhost:tproxy        ESTABLISHED 4935/firefox        
tcp        0      0 localhost:tproxy        localhost:50132         ESTABLISHED 30070/echo-ws-server
NI Andrea for comment 1.
Flags: needinfo?(amarchesini)
Reporter

Comment 3

Last year
I checked current nightly, and can't reproduce. So I guess this will be a WONTFIX, but I'd like to know what fixed the issue to backport it...
If its service worker specific, then it may not be possible to backport.  There have been a lot of infrastructural changes to SW lately.

It could also be that we now call DOMEventTargetHelper::DisconnectFromOwner() from worker globals.  I would also be a bit worried to uplift that.
Reporter

Comment 5

Last year
Bisecting with mozregression leads to the fix being bug 1436784 which looks sensible.
Reporter

Updated

Last year
Status: NEW → RESOLVED
Closed: Last year
Resolution: --- → INVALID
Thanks for filing and investigating!
Flags: needinfo?(amarchesini)
You need to log in before you can comment on or make changes to this bug.