Process a URLPatternInit doesn't call basic URL parser on base URL

[shannonbooth]

What is the issue with the URL Pattern Standard?

process a URLPatternInit does:

Set baseURL to the result of parsing init["baseURL"].

Which has blob handling, which does not seem required. This seems like it should be changed to invoke the basic URL parser instead: https://url.spec.whatwg.org/#concept-basic-url-parser

[shannonbooth]

Another editorial problem I noticed in the same AO is that "process a URLPatternInit" does:

1. Let baseHost be baseURL’s host.
2. If baseHost is null, then set baseHost to the empty string.
3. Set result["hostname"] to the result of processing a base URL string given baseHost and type.

But URL's host is a concept/variant, and is not a string. e.g it may be an ipv4 address which is a 32 bit integer. I believe the spec should be calling this on host's serialization instead (https://url.spec.whatwg.org/#concept-host-serializer). But I can split this into a different issue if preferred (I will probably run into a few of these type of things, I am implementing the spec from scratch).

[shannonbooth]

One more I noticed I can also split out into a different issue, but putting it down here for reference.

Parse a pattern string (https://urlpattern.spec.whatwg.org/#parse-a-pattern-string), step 3.9.1 does:

1. Set prefix be the result of running consume text given parser.

But not prefix is in scope, so I believe should be 'let'. Similar story for modifier token on step 3.9.6

[shannonbooth]

Noticed another thing (I will do a pass over this afterwards and clean up this issue).

Canonicalizing an opaque pathname https://urlpattern.spec.whatwg.org/#canonicalize-an-opaque-pathname

On step 3. does:

3. Set dummyURL’s path to the empty string.

But in this case the URL path is a list. So I guess this must means to set it to a list with one item of the empty string?

[jeremyroman]

re. canonicalize an opaque pathname, the URL path can be either a list of path segments (in the case of a non-opaque path) or a single path segment (in the case of an opaque path). As this is the latter case, I think the spec is correct.

Whether your implementation internally treats this case as a list containing a single path segment plus an opaque flag is up to you, but I believe this is intended to cause the basic URL parser's opaque path state (which expects this to be a string, not a list of strings) to operate correctly.

The other three things you've reported I agree with and have opened pull requests. Thank you very much for pointing them out.

[shannonbooth]

Oh right, thanks! Yeah that last one was my misunderstanding!