Fix loading wasm in electron by falling back to XHR

[0x53A]

fixes mono/mono#20592 (which was my original issue)

should fix #11671

---

see electron/electron#3922

When attempting to reference a relative url (ala scripts/gamename/scenename.xml) fetch will fail with " url scheme "file" is not supported", while an XmlHttpRequest will succeed for the same request.

I did a quick test by editing dotnet.js in my electron output folder, and it seems to work, but would appreciate any feedback.

[welcome]

Thank you for submitting a pull request! If this is your first PR, make sure to add yourself to AUTHORS.

[kripken]

Thanks for the PR @0x53A - I agree we should fix this, but I think we may want a different approach. This regresses code size, which we try to avoid unless absolutely necessary.

I think an approach that can work is the one suggested in #12203 That is, we could create an "electron shim" JS file that replaces fetch, or just assigns it null maybe (if I understood the solution here right - does it just avoid doing a fetch?). If that makes sense, we can maybe find a way to do that even before #12203 is implemented.

[0x53A]

if I understood the solution here right - does it just avoid doing a fetch?

It replaces the fetch with XmlHttpRequest IF the url is file://because fetch does not work with file:// but XHR does.

[kripken]

Ok, then yes, I think that approach can be used here. That is, fetch would be wrapped around, so that it redirects a file URL to an XHR instead. Then that wrapping would be in a file that is only included in builds for electron, which would avoid a code size increase here.

If that makes sense, then I can find time to set up the general infrastructure for adding such a file, if it's not obvious to you where to start for that.

[0x53A]

If I understood you correctly, this would replace (wrap) fetch globally for the whole app? That does sound like it could introduce subtle bugs.

If it is possible to detect electron at build time, wouldn't it be easier to wrap the else branch in #if electron?

I already wrapped the else in ENVIRONMENT_MAY_BE_WEBVIEW, so there is currently NO code size increase in pure web targets.

[kripken]

Oh, I meant to wrap it just inside the emscripten output. Not to modify the global state. (I assume we never want electron to fetch a file URL from our code?)

But yes, if we can just ifdef by the build type then that is even better! Is the remaining code size increase in the diff (on that one test) unintentional then, and can be removed?

[0x53A]

No, the second one (test_INCOMING_MODULE_JS_API) seems to have ENVIRONMENT_MAY_BE_WEBVIEW, so there is a real code size increase.

Only test_small_js_flags was affected by the #ifdef.

[kripken]

I see, thanks - yes, it makes sense for size to increase in that test, then.

[kripken]

does getBinary() not work on Electron? If it allows sync xhrs on the main thread etc., then the addition above may not be necessary.

[0x53A]

getBinary does a synchronous XHR, which is not allowed on the main thread: https://stackoverflow.com/questions/49577319/xmlhttprequest-error-synchronous-xmlhttprequest-on-the-main-thread-is-deprecate

[kripken]

Interesting, even on electron? I thought maybe since it has more APIs than the Web, that includes a way to synchronously get a file.

[0x53A]

Thank you for the review. I finally had some more time for this and I think I've fixed all your comments.
Can you please take a look again?

Regarding

Interesting, even on electron? I thought maybe since it has more APIs than the Web, that includes a way to synchronously get a file.

I think there is a way to mark a protocol as "safe", which might even allow fetch on file, but the goal of this PR is to make WASM in Electron "just work" without every user having to code a workaround.

[kripken]

Sorry for the late response - holidays etc...

Looks good. I added an indentation fix now. Once tests pass, will merge.

[kripken]

Test failures here look like existing issues on trunk, so looks safe to merge.

[0x53A]

Thank you! Hope you had some good holidays, and happy new year, etc ;D

I'll ping the mono team after the next release.