nhiroki: Could you confirm if this is a real problem? I'm not familiar with the spec related to workers.

@shimazu
Here is the relevant part in the spec.
> A worker is said to be a permissible worker if its list of the worker's Documents is not empty, or if its list has been empty for no more than a short user-agent-defined timeout value, its WorkerGlobalScope is actually a SharedWorkerGlobalScope object (i.e. the worker is a shared worker), and the user agent has a browsing context whose Document is not complete loaded.

> The second part of this definition allows a shared worker to survive for a short time while a page is loading, in case that page is going to contact the shared worker again. This can be used by user agents as a way to avoid the cost of restarting a shared worker used by a site when the user is navigating from page to page within that site.

It's clearly stated that shared workers must survive across page reloads. Chrome currently destroy then reinitialize shared workers when users reload pages while there is no other active page.

I didn't think the spec is clear enough for saying that it 'must' survive, but it just says it *allows* shared workers to survive for a short period of time (and the period is user-agent-defined), doesn't it?

@kinuko
I think it should be interpreted as "must" since the spec mentions that shared worker should be alive when "the user agent has a browsing context whose Document is not complete loaded".

lewisween: The quoted bits of the spec in comment #2 are actually not conclusive. The first part is just a definition: what matters is how the algorithms reference this definition (i.e., what they say about "permissible worker"). The second part is a non-normative note. These are just explanatory notes for the reader's convenience, removing them has no material effect on what the spec says.

Anyway, what the spec says is not as important as what other browsers do and what the use case is. Can you provide feedback about other browsers' behavior, and why you're interested in persisting across page reloads?

@falken
> what the use case is
The note has already mentioned it, which is "avoid the cost of restarting a shared worker". So what is really the cost of restarting a shared worker? I think it entirely depends on the application architecture. You can read this comment(https://github.com/whatwg/html/issues/315#issuecomment-244903762) to have some ideas on how shared workers are going to be used. Shared workers are the ideal choice for holding persistent connections (WebSockets, WebRTC connections) or database (IndexedDB) connections. Restarting a shared worker in that case will also restart all those connections initialized within it. So the cost will be very high as the result.

> Can you provide feedback about other browsers' behavior

I didn't test other browsers' behaviour. But I'm pretty sure that they will behave just like Chrome. It's simply because nobody gives a shit about improving shared workers. They even thought about removing it from the spec.

OK. Not sure we'd pick this up but sounds P3/request for improved feature. Would be worth investigating what Firefox does.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot