> 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/52da9fbb-d9c7-4bec-bdb7-abe8a2d0deb6n%40googlegroups.com.
