Edit

Keeping the original discussion for reference/history sake but I ended up explaining why some part of this idea won't work in this MR which has been already tested as working fine #2334

Basically, a polyfill needs to be imported before other scripts and just waiting for scripts on the DOM to optionally have a service-worker attribute, or even waiting for any Worker (Workers are patched by the polyfill, you can see where this is going) to receive or use that service-worker detail, is alway too late to actually fix the broken environment.

My current implementation there provides a different approach:

• if you want to support also non capable browsers, you just land @pyscript/core/service-worker utility/helper right before you land @pyscript/core in your page
• the utility/helper takes care already of not polluting, changing, or modify anything on capable browsers, it does however provide a universal fallback for these too in case people copy/paste the same project in places where those special headers for SharedArrayBuffer are not provided ... it still does nothing if SharedArrayBuffer is there and usable
• the service worker must be, or at least it must contain, the fetch listener from this module and it's provided already optimized and minified for most common use cases where this issue is the only one to solve
• however, the service worker can do much more than just help patching SharedArrayBuffer, all this can be composed and work very well together indeed as long as properly orchestrated

I hope you also like the current approach and I think we need to document this new requirement for whoever was using the service-worker attribute, something we documented too, something I've thought nobody was using ... right now this seems to work fairly well and definitively better than before so maybe we can also remove that big warning from the docs.

The TL;DR reason for discussing this topic is that we currently do not support Safari Desktop and Safari Mobile on PyScript .com but the issue around headers expectations, how these could limit any App potential (to work also in Safari) and all topics around this fundamental requirement are way more common than expected and for good reasons:

• if Cross-Origin-Embedder-Policy: require-corp is used to enable Safari, most embedded stuff and third party scripts, CDNs or services might not work as expected. This was the initial reason to introduce a fallback in PyScript but that fallback was never too popular, although we've recently realized one of the most successful projects based on PyScript was, in fact, using such fallback
• users might not have the power to change their server/host default headers, meaning they need to use (what I consider) "hacks" via ServiceWorker based solutions that enforce those headers without fully solving the original issue
• when synchronous operations are not needed or meant to be used all this friction around headers is pointless. This is why we just show a warning that document and window (or, in general, the DOM) cannot be used when such headers are not around ... yet "what if" we could enable everything, acknowledging that it's going to be inevitably slower and yet it would work occasionally, when those synchronous operations are needed?

A SharedArrayBuffer Polyfill

Meet sabayon and its latest polyfill variant:

• it still need a ServiceWorker to provide its ability to provide Atomics.wait and Atomics.notify that "just work"™️ ... but ...
• it doesn't need, use, or trust that special headers are in place at all: it works without constraining Cross-Origin-Opener-Policy: same-origin and/or Cross-Origin-Resource-Policy: cross-origin and it doesn't need Cross-Origin-Embedder-Policy neither: it uses the ServiceWorker to orchestrate a synchronous XHR request to that file itself and it's been proven to work already (as in: that is what people have been using so far without major complains)
• it can be 100% opt-in: we don't need to add bloat to our core if crossOriginIsolated global reference is already true

Proposal

We add that conditional bootstrap logic for sabayon as fallback so that:

• in Pyscript .com we automatically infer where is the service worker URL, this needs to be available at the root of each user's project and possibly with a unique, non ambiguous, non clashing name, such as /__pyscript_sw_fallback.js ... @mchilvers and @FabioRosado can we do that?
• in all non PyScript .com scenarios users can define pyscript_sw_fallback = "/path_to_sw.js" as a config property and we automatically decide, when it's present and desired, to bootstrap sabayon polyfill

The goal of this proposal in a nutshell:

• even Safari would work as expected (although slightly slower) in PyScript .com without us breaking all projects that assume Cross-Origin-Embedder-Policy: credentialless is in place
• any project outside PyScript .com could suddenly use our workers feature without overdoing the DOM manipulation part but still, they can activate GeoLocation or any other Web API from workers while doing heavy computations without blocking the main thread so that DOM manipulation aside they should be just fine

@ntoll, @danyeaw and @fpliger ... what do you all think about this proposal?