1777450 - Confusing error message when using dynamic import with relative paths when the referrer does not have a valid URL

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect, P2)

Description

[Nicolò Ribaudo]

Consider this JavaScript file:

const p = await import(`data:text/javascript,
  export default import("./foo.js");
`);

await p.default;

It throws this error:

Uncaught TypeError: Error resolving module specifier “./foo.js”. Relative module specifiers must start with “./”, “../” or “/”.

which is super confusing, because ./foo.js starts with ./.

The same happens if you go to the about:blank page and run await import("./foo.js") in the console.

I believe that this happens because the referrer (the "base" from where ./foo.js is resolved) in both cases is not a valid URL: in the first example it's probably the source of the inline imported module, while in the second case it's probably about:blank.

PS: I'm not sure if the component for this bug report should be "DOM: Core & HTML" or "JavaScript Engine"

Comment 1

[Olli Pettay [:smaug][[e-mail]]]

this is not really a javascript engine bug, but since bug 1566307 was filed such, moving also this Core: Javascript Engine.

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1566307

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

:jonco, since you are the author of the regressor, bug 1566307, could you take a look?
For more information, please visit auto_nag documentation.

Comment 4

[Yoshi Cheng-Hao Huang [:allstars.chh][:allstarschh][:yoshi]]

Is this problem can be described as:
import("./foo.js"); // where ./foo.js is a non-exist file

And the error message should be
"TypeError: Error resolving module specifier: ./foo.js" ?

(Without the 'Relative module specifiers must start with “./”, “../” or “/”.')

If that's so, then I could just add another error message for that.
https://searchfox.org/mozilla-central/rev/4654ce1e24a6af17bc96ab60f1f70c218755142f/dom/locales/en-US/chrome/dom/dom.properties#325

Comment 5

[Nicolò Ribaudo]

If I run import("./foo.js") where foo.js does not exist I already get a good error:

TypeError: error loading dynamically imported module

The specifier could be resolved, the problem in this case is that there is no file corresponding to the resolved specifier ("resolving the specifier" happens before trying a network request). I don't think that the error needs to be updated in this case.

Comment 6

[Jon Coppeard (:jonco)]

Attachment: Bug 1777450 - Separate error messages for module resulution failure when the specifier might be bare r=allstarschh!,flod!

This fixes the original case by adding an extra error reason which is used when
the specifier could be bare and and only warning about relative URLs in this
case.

The same problem happens with import maps enable where "./foo.js" produces an
error about it being a bare specifier, which it's not. For that case make
ParseURLLikeImportSpecifier return a ResolveResult and use the same approach.

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/b716f36c4a1c
Separate error messages for module resulution failure when the specifier might be bare r=allstarschh,flod

Comment 8

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/b716f36c4a1c

Comment 9

[BugBot [:suhaib / :marco/ :calixte]]

The patch landed in nightly and beta is affected.
:jonco, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
• If no, please set status-firefox103 to wontfix.

For more information, please visit auto_nag documentation.

Comment 10

[Jon Coppeard (:jonco)]

No, we can let this ride the trains.