Closed Bug 1451975 Opened 3 years ago Closed 3 years ago

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

Categories

(Core :: DOM: Service Workers, defect)

All
Unspecified
defect
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: fabrice, Unassigned)

References

(Blocks 2 open bugs)

Details

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
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)
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.
Bisecting with mozregression leads to the fix being bug 1436784 which looks sensible.
Status: NEW → RESOLVED
Closed: 3 years ago
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.