Skip to content

Use fetch rather than XMLHttpRequest for downloading Wasm files #22015

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 20 commits into from
May 30, 2024

Conversation

seanmorris
Copy link
Contributor

@seanmorris seanmorris commented May 30, 2024

This PR switches requests for Wasm files to be loaded with fetch() rather than XMLHttpRequest().

This fixes running in service workers where XMLHttpRequest is not available.

Partially fixes #22003, only applies to Wasm files.

@seanmorris seanmorris changed the title Separating readAsync fetch from loadPackage fetch. Use fetch() for loading shared libraries May 30, 2024
@seanmorris seanmorris changed the title Use fetch() for loading shared libraries Use fetch() for loading shared libraries May 30, 2024
@sbc100
Copy link
Collaborator

sbc100 commented May 30, 2024

I believe readAsync is also used to load the wasm module itself.. so this effects all users, not just those who have shared libraries. Maybe update the title and description to refer to wasm file loading?

@sbc100 sbc100 changed the title Use fetch() for loading shared libraries Use fetch rather than XMLHttpRequest for download Wasm files May 30, 2024
Copy link
Collaborator

@sbc100 sbc100 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm with a few comments

if (xhr.status == 200 || (xhr.status == 0 && xhr.response)) { // file URLs can return 0
onload(xhr.response);
return;
fetch(url)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you also update the above two uses of XMLHttpRequest ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like the two earlier calls are synchronous, it might take some more re-engineering to get those converted.

@@ -5549,6 +5554,69 @@ def test_webpack(self):
shutil.copyfile('webpack/src/hello.wasm', 'webpack/dist/hello.wasm')
self.run_browser('webpack/dist/index.html', '/report_result?exit:0')

def test_fetch_polyfill_shared_lib(self):
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if we even need to involve shared libraries here since the polyfill is needed even to load the base wasm file (I think).

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Lgtm either way though since you've already gone to the trouble to writing the test.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think its good to have this test either way, that stuff could be changed in the future as the code becomes more unified. We should make sure the code works in all cases.

Copy link
Collaborator

@sbc100 sbc100 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I updated the PR title and description.. I hope thats ok

@sbc100 sbc100 changed the title Use fetch rather than XMLHttpRequest for download Wasm files Use fetch rather than XMLHttpRequest for downloading Wasm files May 30, 2024
@sbc100
Copy link
Collaborator

sbc100 commented May 30, 2024

Actually I was wrong.. it looks like the core wasm file already has a fetch-by-default setup (we can remove this as a followup to this change I hope):

return fetch(binaryFile, {{{ makeModuleReceiveExpr('fetchSettings', "{ credentials: 'same-origin' }") }}}).then((response) => {

@seanmorris seanmorris requested a review from sbc100 May 30, 2024 15:44
Copy link
Collaborator

@sbc100 sbc100 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good!

Just need to figure out what is going on with that common.py change. Otherwise this looks ready to land.

Thanks for you patience on this one.

sbc100 added a commit to sbc100/emscripten that referenced this pull request May 30, 2024
sbc100 added a commit to sbc100/emscripten that referenced this pull request May 30, 2024
@sbc100 sbc100 enabled auto-merge (squash) May 30, 2024 22:20
sbc100 added a commit to sbc100/emscripten that referenced this pull request May 30, 2024
@sbc100 sbc100 merged commit 7e79633 into emscripten-core:main May 30, 2024
29 checks passed
sbc100 added a commit to sbc100/emscripten that referenced this pull request May 30, 2024
In emscripten-core#22015 we switched `readAsync` to be based on fetch rather than
XHR.  However that broke the assumption in `getBinaryenPromise` that was
assuming `readAsync` was XHR-based.

This change reinstates the XHR fallback in the case of webviews where
loading from `file://` URLs is not only possible but (apparently)
common.

Sadly we don't have any webview tests so I have no way to actually test
this within our current frameworks.
@sbc100
Copy link
Collaborator

sbc100 commented May 30, 2024

Oops, I think we overlooked the webview + file-url case. See #22026

sbc100 added a commit to sbc100/emscripten that referenced this pull request May 30, 2024
In emscripten-core#22015 we switched `readAsync` to be based on fetch rather than
XHR.  However that broke the assumption in `getBinaryenPromise` that was
assuming `readAsync` was XHR-based.

This change reinstates the XHR fallback in the case of webviews where
loading from `file://` URLs is not only possible but (apparently)
common.

Sadly we don't have any webview tests so I have no way to actually test
this within our current frameworks.
sbc100 added a commit to sbc100/emscripten that referenced this pull request May 31, 2024
sbc100 added a commit to sbc100/emscripten that referenced this pull request May 31, 2024
sbc100 added a commit to sbc100/emscripten that referenced this pull request May 31, 2024
In emscripten-core#22015 we switched `readAsync` to be based on fetch rather than
XHR.  However that broke the assumption in `getBinaryenPromise` that was
assuming `readAsync` was XHR-based.

This change reinstates the XHR fallback in the case of webviews where
loading from `file://` URLs is not only possible but (apparently)
common.

Sadly we don't have any webview tests so I have no way to actually test
this within our current frameworks.
dschuff pushed a commit that referenced this pull request May 31, 2024
In #22015 we switched `readAsync` to be based on fetch rather than
XHR.  However that broke the assumption in `getBinaryenPromise` that was
assuming `readAsync` was XHR-based.

This change reinstates the XHR fallback in the case of webviews where
loading from `file://` URLs is not only possible but (apparently)
common.

Sadly we don't have any webview tests so I have no way to actually test
this within our current frameworks.
msorvig pushed a commit to msorvig/emscripten that referenced this pull request Jun 4, 2024
…mscripten-core#22015)

This PR switches requests for Wasm files to be loaded with `fetch()` rather than `XMLHttpRequest()`.

This fixes running in service workers where `XMLHttpRequest` is not available.

Partially fixes emscripten-core#22003, only applies to Wasm files.
msorvig pushed a commit to msorvig/emscripten that referenced this pull request Jun 4, 2024
In emscripten-core#22015 we switched `readAsync` to be based on fetch rather than
XHR.  However that broke the assumption in `getBinaryenPromise` that was
assuming `readAsync` was XHR-based.

This change reinstates the XHR fallback in the case of webviews where
loading from `file://` URLs is not only possible but (apparently)
common.

Sadly we don't have any webview tests so I have no way to actually test
this within our current frameworks.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Can't preload files/shared libs in service worker due to lack of XHR [PR OPEN]
2 participants