UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:57.0) Gecko/20100101 Firefox/57.0

Steps to reproduce the problem:
In DevTools console, compare the behaviors of:

(1) new URL("http://xn--google.com")
(2) new URL("http://䕮䕵䕶䕱.com")
(3) new URL("http://xn--x.com")
(4) new URL("http://xn--x.xn--google.com")
(5) new URL("http://xn--x.䕮䕵䕶䕱.com")

Also try navigating to these URLs via the address bar.

What is the expected behavior?
All 5 examples should create a URL object.

Note that (1) and (2) result in identical URLs, because (1) is simply the punycode representation of (2); in both cases, the resulting URL has its hostname set to "xn--google.com".

Example (3) also looks like punycode, but is not actually a valid punycode label. This does not prevent 'new URL()' from parsing it, with a resulting hostname of "xn--x.com", although the difference from (1) can be seen by trying to navigate there: (1) will display as 䕮䕵䕶䕱.com in the address bar (and resolves to a parked-site page), whereas (3) results in a web search because it cannot be resolved.

Example (4) shows that the presence of the invalid-punycode label  as a subdomain does not interfere with parsing the URL as a whole, nor with navigating to the site: this will also lead to a parked-site page for 䕮䕵䕶䕱.com.

Example (5) should behave identically to (4), just like (2) behaves identically to (1).

What went wrong?
Example (5) in the Dev Tools console results in failure:

> Uncaught TypeError: Failed to construct 'URL': Invalid URL

I believe this is incorrect, AFAICT from reading the reading the URL parsing algorithm[1].

The algorithm depends on a "host parser"[2] which in turn uses a "domain to ASCII"[3] algorithm based on Unicode's ToASCII[4]. This basically splits the domain on dots, and then punycode-encodes any labels that contain non-ASCII characters; but I don't see anything that requires an invalid-ACE label like "xn--accountlogin" to result in a validation failure, nor any justification for treating this differently depending on whether a separate label within the domain contained non-ASCII chars (and therefore was punycode-encoded by ToASCII).

[1] https://url.spec.whatwg.org/#concept-basic-url-parser
[2] https://url.spec.whatwg.org/#concept-host-parser
[3] https://url.spec.whatwg.org/#concept-domain-to-ascii
[4] http://www.unicode.org/reports/tr46/#ToASCII

Did this work before? N/A 

Does this work in other browsers? Yes

Chrome version: 60.0.3112.90 (Official Build) (64-bit)  Channel: stable
OS Version: OS X 10.12
Flash Version: Shockwave Flash 23.0 r0

Note that Safari behaves as expected here (examples 4 and 5 both parse to identical URLs), as does Firefox once mozilla bug 1399540 (just landed, to address a couple of somewhat different-but-related issues) is fixed.