1901810 - Parsing <file:///c|> against <about:blank> on Windows

Status: NEW

(Core :: Networking, defect, P2)

Description

[Sean Kim [:sekim]]

As shown by Bug 1895233 (try result without Windows guard blocks) https://treeherder.mozilla.org/push-health/push?repo=try&revision=bd943bfb695ec6bbdde568c749176b44df8daaf4&tab=tests&testGroup=pr&selectedTest=netwerktestunitteststandardurljs&selectedTaskId=460410053&selectedJobName=netwerk%2Ftest%2Funit%2Ftest_standardurl.js+test-windows11-64-2009-qr%2Fopt-xpcshell-4

Parsing <file:///c|> against <about:blank> on Windows does not work:
https://jsdom.github.io/whatwg-url/#url=ZmlsZTovLy9jfA==&base=YWJvdXQ6Ymxhbms=

How to reproduce:
Add the following block to netwerk/test/unit/test_standardurl.js (test_verticalBar):
https://searchfox.org/mozilla-central/source/netwerk/test/unit/test_standardurl.js#502-519

  url = Services.io.newURI("file:///c|");
  Assert.equal(url.spec, "file:///c:");

Try result (Windows) or local result on Windows VM:

TEST-UNEXPECTED-FAIL | netwerk/test/unit/test_standardurl.js | test_verticalBar - [test_verticalBar : 519] "file:///c:/" == "file:///c:"

There are a few locations of interest that might be causing the issue:
https://searchfox.org/mozilla-central/rev/dc08a7321a22918d5a26b7641f9b10cd2a09d98e/netwerk/base/nsURLParsers.cpp#392-416

Comment 1

[Sean Kim [:sekim]]

Adding this in testing/web-platform/tests/url/resources/urltestdata.json should pass on Try:

  {
    "input": "file:///c|",
    "base": null,
    "href": "file:///c:",
    "protocol": "file:",
    "username": "",
    "password": "",
    "host": "",
    "hostname": "",
    "port": "",
    "pathname": "/c:",
    "search": "",
    "hash": ""
  },

Comment 2

[Valentin Gosu [:valentin] {{ PTO 3 July - 3 August }}]

(In reply to Sean Kim from comment #0)

There are a few locations of interest that might be causing the issue:
https://searchfox.org/mozilla-central/rev/dc08a7321a22918d5a26b7641f9b10cd2a09d98e/netwerk/base/nsURLParsers.cpp#392-416

My bet is on this one. I don't think nsStandardURL::GetRelativeSpec would get called when parsing the URL.

And most likely the / is being added here.

Basically I think the windows specific implementation of ParseFilePath isn't doing the right thing. Maybe we can get away with removing it completely (URL parsing shouldn't be platform dependent).