Re: [whatwg/url] Review slashes after file:/// and file path normalization (#405)

Looking at https://wpt.fyi/results/url/url-constructor.html?label=pr_head&max-count=1&pr=25716 (which is generated from https://github.com/web-platform-tests/wpt/pull/25716#event-3798606232) most things look good, but there is a section of tests which fail in more browsers more than would be ideal:

- `Parsing: </..//localhost//pig> against <file://lion/>`, `Parsing: </rooibos> against <file://tea/>`, and `Parsing: </?chai> against <file://tea/>` fail in Firefox and Safari, passing only in Chrome.

- `Parsing: <C|> against <file://host/dir/file>` through `Parsing: <C|\> against <file://host/dir/file>` fail in all three browsers.

- `Parsing: <C|a> against <file://host/dir/file>` fails in Chrome and Firefox, passing in Safari.

- `Parsing: </c:/foo/bar> against <file://host/path>` fails in Firefox and Safari, passing in Chrome.

It looks like most of the cases with 2 failures were also 2 failures before (referencing https://wpt.fyi/results/url/url-constructor.html?label=master&label=experimental&product=chrome&product=firefox&product=safari&aligned), albeit sometimes a different 2. So that's not a regression. Indeed, in cases where all 3 browsers give different results, that's the best we can hope for.

But the conversion of some of them from 2-failures to 3-failures seems suboptimal. It seems to be concentrated around `C|`-style drive letter handling. Do you think there's something that could be tweaked there to match at least one browser?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/url/issues/405#issuecomment-697730239