You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The hostname pattern is an IPv6 address steps except a pattern string but in the initialize steps it can directly be called with null when hostname isn't present in the argument passed to the constructor :
If the result running hostname pattern is an IPv6 address given processedInit["hostname"] is true, then...
Yes, this algorithm assumes that getting the value of a map returns null for absent entries, but that's not what map/get does (it asserts that the entry is present). Let me see what the simplest way to fix that is.
Currently, some steps in "initialize a URLPattern" access potentially nonexistent entries in the processedInit map, and expect "compile a component" to receive these as null, even though it requires a string.
Instead, these entries are now always populated after calling "process a URLPatternInit" so that subsequent steps can depend on a valid string.
Since the comparison with the default port requires that the two types be the same, fix that too.
Fixes#209.
What is the issue with the URL Pattern Standard?
The hostname pattern is an IPv6 address steps except a pattern string but in the initialize steps it can directly be called with
null
when hostname isn't present in the argument passed to the constructor :The hostname pattern is an IPv6 address steps then fail to check its
null
input code point length:This issue is related the
null
default value issue discussed hereThe text was updated successfully, but these errors were encountered: