Keep shared worker alive when activating portal

[Daniel Olano]

Following this SO question browsers don't persist shared workers when navigating to a new page or refreshing(apparently an undefined behavior in the spec?) which is a shame because many would benefit from that feature, specially relevant for people trying to persist a costly websocket or webRTC data channel. I think it's something that should be solved for the normal navigation but since it looks unlikely to be solved what about shared worker persistence when navigating using portals? Seems like an undefined behavior again as It's not mentioned in the draft, it probably isn't hard to implement as the new page is created while the previous one is around, right? it might even work already?

Portals are a nice gimmick but not life changing, want to add a killer feature that alone can convince people to use them? Consider persistence of shared workers! 😃

[Domenic Denicola]

I think this automatically falls out of the current spec, since the browsing context is never destroyed. So shared workers should be kept alive. (Killing them on navigation is defined behavior; they become no longer "protected workers".)

We should probably write web platform tests ensuring this is the case.