Repository navigation
Component match results are not intuitive for patterns with RegExp having named-capture groups #284
Description
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
Activity
annevk commentedon Jun 26, 2026
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 commentedon Jul 15, 2026
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/