Chrome Version: 63
OS: Linux

What steps will reproduce the problem?
(1) Open JavaScript console.
(2) Type: new URL('https://xn--abcdé')
(3) Type: new URL('https://ab--abcdé')

What is the expected result?
URL { href: "https://xn--xn--abcd-i1a/", ... }
URL { href: "https://xn--ab--abcd-i1a/", ... }

What happens instead?
Uncaught TypeError: Failed to construct 'URL': Invalid URL
Uncaught TypeError: Failed to construct 'URL': Invalid URL

Spec compliance: I don't see any reason in URL Standard [1] why this should be considered an invalid URL; certainly not the second case (starting with "ab--"). Works correctly in Firefox.

What's happening here?

The URL is tricky: the one in step (2) appears to be in IDNA form (Punycode-encoding some Unicode domain), but it actually contains a non-ASCII character, so is therefore illegal Punycode. However, the URL Parser in [1] *does not* attempt to parse/decode Punycode at all (that is a rendering consideration only). The parser's job is to *encode* non-ASCII characters into Punycode form.

Therefore, the correct behaviour is to detect the 'é' character, and thus encode the Unicode domain "xn--abcdé" into Punycode form: "xn--xn--abcd-i1a". (The fact that the domain starts with "xn--" should be irrelevant; it prepends a new "xn--" to the front.) Chrome seems to be trying to parse the illegal Punycode domain at URL parse time, resulting in an error.

Even weirder, it seems you can put *any two unreserved characters* (ASCII alphanumeric, '-', '_', '.' or '~') before the "--", to hit the same error. Hence, strings starting with "ab--", "7~--" or even "----" result in this error. Those are perfectly legal URLs.

Found while investigating  Issue 804462 .

[1] https://url.spec.whatwg.org/