"bad module specifier in a dependency" in dynamic-imports-script-error.html should be updated

[allstarschh]

This is discovered when working on https://phabricator.services.mozilla.com/D269568

bad module specifier in a dependency was used to test the ParseError generated when resolving failed in creating module script, therefore it should be the same error object when calling import() twice.

https://web.archive.org/web/20221130023614/https://html.spec.whatwg.org/#creating-a-javascript-module-script

10. For each ModuleRequest record requested of result.[[RequestedModules]]:

    1. Let url be the result of resolving a module specifier given script and requested.[[Specifier]], catching any exceptions.

    2. If the previous step threw an exception, then:

        1. Set script's parse error to that exception.

However, the current spec doesn't iterate [[RequestedModules]] anymore; instead, it throws the resolutionError when the resolution fails.

See HostLoadImportedModules, step 7.2
and step 8, and is then propagated through FinishLoadingImportedModule to the
reject handler in ContinueDynamicImport, step 1.

Therefore, for the test, it should also have the option { differentErrorObjects: true }

CCing @nicolo-ribaudo

[nicolo-ribaudo]

This change was actually not intentional 🤔
Let me see if it's is possible to restore the old behavior.

[nicolo-ribaudo]

To restore the old behavior, we would need to store the error returned in step 7.1.3.2 (and 7.1.1.3 and 7.1.5.3?) as the referrer module script's parser error?

[nicolo-ribaudo]

For what is worth, with https://github.com/tc39/proposal-esm-phase-imports and dynamic import maps somebody might:

• const mod = import.source() of a module that internally has an unresolvable specifier
• make that specifier resolvable by installing a new import map
• import(mod) to finish importing that module, and it should not throw an error because at this point we load its dependencies and that succeeds thanks to the new import map

There is a call of the TC39 modules group tomorrow, I'll try to get some feedback there (and if you want to join, ask to your colleagues that work on TC39 for the link to the TC39 calendar :) )

[nicolo-ribaudo]

Maybe the error could be stored not as a parser error but as a new "dependencies error" field, and that is re-thrown as the first thing inside step 7.

[nicolo-ribaudo]

I opened whatwg/html#11820 to figure out what behavior we actually want.