whatwg / html

HTML Standard
https://html.spec.whatwg.org/multipage/
Other
8.11k stars 2.67k forks source link

Keep sharedWorker alive durning reload / next-page #9278

Open jimmywarting opened 1 year ago

jimmywarting commented 1 year ago

While searching for a solution to keep SharedWorker alive durning reload and keeping the state intact and not having to fetch all the resources over again and again durning page reload / navigation when only having one tab open

i found out that my SharedWorker was terminated when the current page died. and the state in the shared worker where lost. i only have one tab open but i would wish for it to stay alive to the next page.

I happen to stumble upon this in the spec:

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.

https://html.spec.whatwg.org/multipage/workers.html#the-worker's-lifetime

I tried every way i could think of to keep the SharedWorker alive but it ended in failure. Tried reload the page, tried navigating to a page where also about to try portals but that trail period have ended and i don't see a chrome flag for it anymore. maybe it was something about being replaced with "View Transition"

annevk commented 1 year ago

Can you demonstrate this using a test in web-platform-tests?

jimmywarting commented 1 year ago

I could not find any existing test that tested the lifetime of SharedWorker durning reload. I think only Service Worker can stay alive durning a reload / page navigation.

annevk commented 1 year ago

That's not how shared workers are defined. I recommend writing a test.

jdeepwell commented 5 months ago

I ran into the same issue. I also need the Shared Worker to stay alive during page transitions. I am creating a WebSocket connection in it and it would be bad if that was re-created over and over again for each page transition.

After some testing I was able to boil it down to something testable (see attached files).

The Shared Worker seems to be restarted in the following scenario:

As long as the pages do not have the Cache-Control header, everything is fine (the Shared Worker does not get restarted on page transitions). Even when the pages are really fetched from the server! - I made sure they are when using the navigation links by appending a random query (and checking on the server side that they really are fetched).

So the fact that the pages are actually loaded from the server (and not served from the cache) is not the issue.

It's when the pages have Cache-Control headers that prevent caching that leads to the Shared Worker being restarted.

Test

(attached)

When using the example as is you can navigate between the pages and the Shared Worked will keep running from page transition to page transition.

It is only when you enable the remarked lines that generate the header that it stops working - then the Shared Worked will be restarted with every page transition.

Tested with Chrome 124.0.6367.202 (Official Build) (arm64) and Firefox 125.0.3 (64-bit) on macOS 14.4.1 (23E224).


Remark

Keeping Shared Workers alive during page transitions to me seems like an essential part of the definition and purpose of a Shared Worker. The "shared" to me not only means shared between windows/tabs but also shared between pages/requests within a single window/tab. It would be a shame if we had to fall back on Service Workers all the time for such behaviour.

And if the Shared Workers are behaving as stated in the documentation ("...shared worker to survive for a short time while a page is loading...") then I see no reason why this should depend on the caching policy of the page resources using the code that uses the worker (if anything then maybe the caching policy for the Shared Worker code resource itself).

SharedWorkerDying.tgz