The problem: 
With classic, multi-page Web sites, processing of data and network events are limited in their lifetime by the lifetime of the single page. There  is no persistence across pages on the same site.

Example use case:
A user on a Web site which has user profiles uploads a profile image. He cannot browse to another page before the image upload has been finished.

At a first glance, shared Web workers seem to provide a solution, see e.g. comments at	
- http://stackoverflow.com/questions/10886910/how-to-maintain-a-websockets-connection-between-pages/10889098#10889098
- http://stackoverflow.com/questions/14583812/how-to-keep-pusher-client-objects-persistent-across-pages/14601415#14601415http://stackoverflow.com/questions/9336774/do-shared-web-workers-persist-across-a-single-page-reload-link-navigation

According to the spec, with only a single browser tab, the unload/load must lead to the Web worker's closing flag being set to 'true'. 
In a sample current implementation (Chrome 34.0.1843.0), it is possible to produce cases where the shared Web worker persists - but these lie outside of normal use parameters. 
In any case, there can be no assurance for persistence.

Proposed solution:
When a browser determines that the page to load has the same origin as the present page which instantiated a shared Web worker, then it persists this Web worker.

Persistence could be until a defined event has passed without the new page instantiating the shared Web worker.
This could e.g. be the parsing of the document, without any inline script or synchronously loaded script having made the request.