Component match results are not intuitive for patterns with RegExp having named-capture groups

[azaika]

What is the issue with the URL Pattern Standard?

The "create a component match result" algorithm (link) expects the "group name list" and "groups" to have the same length when reconstructing the name from the RegExp match results at step 5.1.

However, when the input pattern has any RegExp parts with named-capture groups, the correspondence becomes inaccurate and results in a very non-intuitive output. For example, new URLPattern({pathname: "/:foo((?<x>xxx))/:bar"}).exec({pathname: "/xxx/yyy"}) results in :bar matches to xxx, which is for the ?<x> RegExp group as the RegExpBuiltinExec output, not yyy.

The original firefox issue (found this behavior first): https://bugzilla.mozilla.org/show_bug.cgi?id=2020156

[annevk]

Maybe @wanderview knows why this is the case, but I doubt this is something that can be changed at this point. Also not sure what we'd change it to.

[wanderview]

The spec attempts to block capturing groups in regexps. See step 4.8.5.6.5 (my kingdom for links to steps...) in:

https://urlpattern.spec.whatwg.org/#tokenize

Link to highlight: https://urlpattern.spec.whatwg.org/#tokenize:~:text=If%20tokenizer%E2%80%99s%20code%20point%20is%20not%20U,start%2C%20and%20tokenizer%E2%80%99s%20index.

I think this example bypasses the proactive check by nesting the capturing group below the top level.

Note, the example pattern doesn't work in path-to-regexp 1.7 or 2.0 either according to: https://forbeslindesay.github.io/express-route-tester/