Run importScripts() fetching steps in parallel #3827
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Fixes #3775. As noted there in more detail, this doesn't change much of the semantics. Execution order is still synchronous, and errors are still thrown in the same deterministic fashion for both network failures and script-running failures. Indeed, Gecko already implements these semantics. It's likely that at the time this specification was originally written, whether these fetches were in parallel or sequential was not observable, at least by client-side code. However, these days, with the web performance APIs and with service workers, it's very observable, and we should be sure that parallel fetching is allowed. For reference, here is a 2015-08-27 snapshot of this method, before any of the script-loading refactorings and changes due to module scripts: https://html.spec.whatwg.org/commit-snapshots/c9e804f04d03a0658bfa689cb0f368a4d2e37936/#dom-workerglobalscope-importscripts You can see that it was sequential even then.
|
Do you want to rebase this? Happy to review. |
|
I got discouraged since nobody seems up for writing web platform tests. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #3775.
As noted there in more detail, this doesn't change much of the
semantics. Execution order is still synchronous, and errors are still
thrown in the same deterministic fashion for both network failures and
script-running failures. Indeed, Gecko already implements these
semantics.
It's likely that at the time this specification was originally written,
whether these fetches were in parallel or sequential was not observable,
at least by client-side code. However, these days, with the web
performance APIs and with service workers, it's very observable, and we
should be sure that parallel fetching is allowed.
For reference, here is a 2015-08-27 snapshot of this method, before any
of the script-loading refactorings and changes due to module scripts:
https://html.spec.whatwg.org/commit-snapshots/c9e804f04d03a0658bfa689cb0f368a4d2e37936/#dom-workerglobalscope-importscripts
You can see that it was sequential even then.
@nilpatelmicrosoft, @wanderview, and @nhiroki, would you be able to help with web platform tests for this? I'm not sure what kind of tests to write, though, since it still seems like implementing sequential fetching would be a valid implementation of this new spec... Thoughts apprecaited.
💥 Error: Wattsi server error 💥
PR Preview failed to build. (Last tried on Jan 15, 2021, 7:58 AM UTC).
More
PR Preview relies on a number of web services to run. There seems to be an issue with the following one:
🚨 Wattsi Server - Wattsi Server is the web service used to build the WHATWG HTML spec.
🔗 Related URL
If you don't have enough information above to solve the error by yourself (or to understand to which web service the error is related to, if any), please file an issue.