Confusing "async" completion of script fetching

[domenic]

Pointed out by @jonco3.

The script fetching algorithms all use an "asynchronous completion" framework, which is not very well-defined. See whatwg/infra#181.

In particular, several people assume that "async" means "queue a task". But it's quite possible to not end up queuing a task, e.g. if you "fetch the descendants of and instantiate" a module with no descendants. So then the presence of the words "when this asynchronously completes" causes confusion.

The particular case we were concerned with was "prepare a script" step 25 for src-less module scripts, which says

Fetch the descendants of and instantiate script, given the destination "script". When this asynchronously completes, set the script's script to the result. At that time, the script is ready.

In code, the case in question is a classic inline script that inserts a module inline script:

<script>
console.log(1);

const s = document.createElement("script");
s.type = "module";
s.textContent = "console.log(2);";
document.body.appendChild(s);

console.log(3);
</script>

There are a couple of possible dimensions of consistency here:

1. Have no-dependency module scripts be consistent with classic scripts, and have them execute immediately (logs 1 2 3).
2. Have no-dependency module scripts be consistent with dependency-having module scripts, and have them execute from a queued task (logs 1 3 2).

Currently the spec picks (1), but in a confusing way because of the use of the word "asynchronously" which causes people to think maybe it's (2).

/cc @whatwg/modules. I'd love folks thoughts on whether (1) or (2) is more natural.

Side note: if we pick (2), then we should remove the "set currentScript to null" logic inside "execute a script block", since currentScript will always be null anyway.

Also, I might have gotten something wrong here, as this is subtle stuff; please feel free to check my logic.

[hiroshige-g]

In the example, I expect the module script is evaluated in the "deferred" timing, and thus the result is (2), no matter whether fetch the descendants of and instantiate completes synchronously or asynchronously. This is the current behavior of Chromium.

I feel (2) is more consistent, in that module scripts are always asynchronous and non-parser-blocking.

[domenic]

Thanks. I might have gotten lost in the spec; would you be able to check my reasoning on which part of the spec calls "execute a script block" in this case?

My reading is that we reach the If the script's type is "module" case in step 26, which says

When the script is ready, execute the script block and then remove the element from the set of scripts that will execute as soon as possible.

and step 25 says

Fetch the descendants of and instantiate script, given the destination "script". When this asynchronously completes, set the script's script to the result. At that time, the script is ready.

So "the script is ready" immediately (synchronously).

Did I miss something?

[hiroshige-g]

Or, sorry, you are correct. I missed the parser-inserted check in the first clause of Step 26.

Still, (2) is the current behavior of Chromium, because for module scripts Chromium considers the script is ready always asynchronously.

[domfarolino]

Just for completeness, I added a tentative WPT for this over in web-platform-tests/wpt#39205.

[nicolo-ribaudo]

The spec now explicitly does (2), probably since #8253 that made the loading process consistently await the "loadingPromise" returned by ECMA-262's LoadRequestedModules() regardless of the number of dependencies.