This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
I noticed something strange writing tests for iso-2022-jp (not uploaded yet). If I had a url like https://example.com/?\0x0E\0x0F\0x1B it would come out as (looking at .search anyway) https://example.com/? but if I had a trailing "s" it would come out as https://example.com/?%0E%0F\x1Bs which together demonstrates two bugs in the specification algorithm, if we want to align with Gecko, Safari, and Chrome here.
I realized this might actually be a side effect of initial stripping of code points around a URL before parsing, since I was using the <a> element. That seems far more likely the thing that needs investigation and whether all URL parsing contexts need to share that.
Fixed through https://github.com/whatwg/url/commit/0bab926668566ca3689f47372501b8980cb08073