Incorrect "starts with" order of newImportMapImports' specifier and resolved module set's specifier in ` merge existing and new import maps`

[allstarschh]

What is the issue with the HTML Standard?

https://html.spec.whatwg.org/#merge-existing-and-new-import-maps

6. For each record of global's resolved module set:
  1. For each specifier → url of newImportMapImports:
     1. If specifier starts with record's specifier, then:
        ....
        2. Remove newImportMapImports[specifier].
        

I think in Step 6.1.1, the two strings are reversed; the correct one should be

6.1.1.  If specifier is a code unit prefix of record's specifier

or

6.1.1. If record's specifier starts with specifier

Take WPT /import-maps/not-overridden/prefix.html as an example
first it imports "resources/log.js?pipe=sub&name=A"

Then adds an import map with imports, with an entry of 'resources' : '/foobar'

Finally, it uses import.meta.resolve("/resources/log.js?pipe=sub&name=A") to get the resolved URI

According to the spec,
when the import map is merged,
the specifier "../resources/" doesn't start with the resolved module set's specifier "resources/log.js?pipe=sub&name=A", so the entry will be added into the import map, which will map the "/resources/" to "/foobar" in the following import.meta.resolve call, and make the test fail unexpectedly.

Now with the updated spec, the resolved module set's specifier starts with the specifier in the new import map's imports, so the entry in the new import map will be removed, and the test will pass correctly.

The other WPTs
"/import-maps/multiple-import-maps/already-resolved-dropped.html"
"/import-maps/not-overridden/dynamic.html" are also be used to indicate that the order is wrong.

CC @yoavweiss and reviewers @domenic @guybedford

[guybedford]

Took a brief look at this this afternoon and I'm not sure I follow the above logic. Specifically, specifier here is supposed to already be a normalized URL, since it should already have gone through sorting and normalizing a module specifier map for the scope per the original parsing.

So there should be no "../resources/" key in the scope at merge time, instead it should be "https://base/resources/".

Then when doing the merge, the fix should surely be to do the check against the URL-resolved specifiers. i.e. checking record's specifier as a URL first, and treating these as two separate specifier cases - both URL-like versus both bare specifier-like.

Please let me know if I'm missing anything and thanks for the quick investigation here.

[guybedford]

Assuming in the above you're talking about normalized URLs though, the semantics around switching the ordering of the check makes complete sense to me.

[allstarschh]

Assuming in the above you're talking about normalized URLs though, the semantics around switching the ordering of the check makes complete sense to me.

Yes, the specifier from the newImportMapImports and the record's specifier from the resolved module set are both normalizedSpecifiers.

See Step. 6.1.1 from
https://html.spec.whatwg.org/#merge-existing-and-new-import-maps

For reference,
When a module is added to the resolved module set,
the specifier is normalized.

Same for the specifierKey in the import map's imports
It is normalized during sort and normalize a module specifier map, Step 2.1

2.1 Let normalizedSpecifierKey be the result of normalizing a specifier key given specifierKey and baseURL.