-
Notifications
You must be signed in to change notification settings - Fork 3.4k
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
Use fetch
rather than XMLHttpRequest
for downloading Wasm files
#22015
Conversation
fetch()
for loading shared libraries
I believe |
fetch()
for loading shared librariesfetch
rather than XMLHttpRequest
for download Wasm files
There was a problem hiding this 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) |
There was a problem hiding this comment.
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
?
There was a problem hiding this comment.
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): |
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this 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
fetch
rather than XMLHttpRequest
for download Wasm filesfetch
rather than XMLHttpRequest
for downloading Wasm files
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): Line 660 in cb99414
|
There was a problem hiding this 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.
…owserCore.compile_btest
…owserCore.compile_btest
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.
Oops, I think we overlooked the webview + file-url case. See #22026 |
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.
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.
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.
…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.
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.
This PR switches requests for Wasm files to be loaded with
fetch()
rather thanXMLHttpRequest()
.This fixes running in service workers where
XMLHttpRequest
is not available.Partially fixes #22003, only applies to Wasm files.