Wrong place to whine about it I guess, but it would be really great if those COOP/COEP response header requirements could also be defined *inside* the index.html as meta-tags (or some sort of 'manifest file' uploaded together with index.html etc to the web server). Because otherwise multi-threaded WASM will never be an option when using hosting services where the user has no control over the web server configuration (such as github-pages).
Hrmpf, not a big fan of this feature... On Friday, 4 December 2020 at 09:02:58 UTC+1 [email protected] wrote: > > I'm not an expert on COOP/COEP, but I don't think you need to build the > module differently. > > You may need to change the webserver's responses > > *In theory*...you should only need the headers to be on your main > "index.html" to get the ball rolling. Then you could use the crossorigin > attribute to get around it on sites you don't fully control, by writing > `<script src="..." crossorigin="anonymous" />` (note that when doing this > programatically on DOM elements, it's `crossOrigin`) > > Having this `crossorigin` workaround is important, as sites like S3--that > are good for hosting the kinds of large files Emscripten makes--do not > offer these headers. > > *In practice*, you run into problems with web workers, as they can't > access the DOM to build script tags. Instead they load using > `importScripts()` which has no `crossorigin` exemption. D'oh. > > QUESTION: Since there's already a common practice of pre-fetch()'ing web > worker source in order to `URL.createObjectURL(workerJsBlob)` ... might it > be possible to have a mode where there is only one .js file with all the > cwraps/etc. that is polymorphic, and can act as either worker-or-not? Then > the workerJsBlob would have everything it needed and would not need to use > importScripts(). Hence the createObjectURL workaround would be enough in > situations where you are using S3 or other hosts, where complete header > control is not an option. > > (At first I thought of just doing that on the fly by fetch()'ing the two > parts and fusing them together in JS, replacing `importScripts()` with an > `importScriptsHack()` that eval()'d the cwrap JS. But given the > immutability of blobs and JS strings that's all going to be pretty > inefficient. But if it were something a build switch could do, it would > not be that bad...the wasm file is a lot bigger than the .js, at least in > my case...and the wasm can be loaded by the main thread where crossorigin > is available.) > > > On Tuesday, June 2, 2020 at 4:34:11 PM UTC-4 Alon wrote: > >> This will affect all browsers eventually, as it is the agreed direction >> in the standards bodies. >> >> I'm not an expert on COOP/COEP, but I don't think you need to build the >> module differently. You may need to change the webserver's responses, >> though. See for example what our browser test suite does, >> >> >> https://github.com/emscripten-core/emscripten/blob/20ecfa2f8101fb21a9c0f9d75e3aa2dee6468e95/tests/runner.py#L1332 >> >> On Tue, Jun 2, 2020 at 12:52 PM Dan C wrote: >> > > >> I noticed this message when loading threaded wasm with Firefox. >>> *Worker.postMessage: The WebAssembly.Memory object cannot be serialized. >>> The Cross-Origin-Opener-Policy and Cross-Origin-Embedder-Policy HTTP >>> headers will enable this in the future.* >>> My understanding is that this is caused by >>> https://bugzilla.mozilla.org/show_bug.cgi?id=1562663 >>> >>> Is this problem something we expect to ever impact any other browsers or >>> is it Firefox only? Would this problem be fixed in Firefox or the module >>> needs to be built differently? >>> >> -- You received this message because you are subscribed to the Google Groups "emscripten-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/3287df53-2371-42f5-bc68-107bdc5be223n%40googlegroups.com.
