Repository navigation
Bug in WHATWG URL parsing #41220
Copy link
Copy link
Closed
Labels
whatwg-urlIssues and PRs related to the WHATWG URL implementation.Issues and PRs related to the WHATWG URL implementation.
Description
Version
v16.13.1
Platform
Linux evilebottnawi 5.4.0-90-generic #101-Ubuntu SMP Fri Oct 15 20:00:55 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
Subsystem
No response
What steps will reproduce the bug?
Code:
console.log(new URL("chrome-extension://__MSG_@@extension_id__/895c2722a512d5b2e333.png"))output:
URL {
href: 'chrome-extension://__MSG_%40@extension_id__/895c2722a512d5b2e333.png',
origin: 'null',
protocol: 'chrome-extension:',
username: '__MSG_%40',
password: '',
host: 'extension_id__',
hostname: 'extension_id__',
port: '',
pathname: '/895c2722a512d5b2e333.png',
search: '',
searchParams: URLSearchParams {},
hash: ''
}
Then run the same code in browser (chrome):
URL {
hash: ""
host: "extension_id__"
hostname: "extension_id__"
href: "chrome-extension://extension_id__/895c2722a512d5b2e333.png"
origin: "chrome-extension://extension_id__"
password: ""
pathname: "/895c2722a512d5b2e333.png"
port: ""
protocol: "chrome-extension:"
search: ""
searchParams: URLSearchParams {}
username: ""
[[Prototype]]: URL
}
Look at username, they are different.
But if we will try firefox:
URL { href: "chrome-extension://__MSG_@@extension_id__/895c2722a512d5b2e333.png", origin: "null", protocol: "chrome-extension:", username: "", password: "", host: "", hostname: "", port: "", pathname: "//__MSG_@@extension_id__/895c2722a512d5b2e333.png", search: "" }
hash: ""
host: ""
hostname: ""
href: "chrome-extension://__MSG_@@extension_id__/895c2722a512d5b2e333.png"
origin: "null"
password: ""
pathname: "//__MSG_@@extension_id__/895c2722a512d5b2e333.png"
port: ""
protocol: "chrome-extension:"
search: ""
searchParams: URLSearchParams { }
username: ""
<prototype>: URLPrototype { toJSON: toJSON(), toString: toString(), href: Getter & Setter, … }
Output is not the same as Node.js/chrome
Not sure it is real bug on Node.js, because we have three different outputs, or in specification, maybe we will find the answer here
How often does it reproduce? Is there a required condition?
Always
What is the expected behavior?
The same output
What do you see instead?
No response
Additional information
Original issue webpack/webpack#15012
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
whatwg-urlIssues and PRs related to the WHATWG URL implementation.Issues and PRs related to the WHATWG URL implementation.
Activity
jasnell commentedon Dec 17, 2021
Node.js' output is the correct one here per the WHATWG spec.
alexander-akait commentedon Dec 17, 2021
@jasnell What is strange, because chrome uses these strange examples in docs https://developer.chrome.com/docs/extensions/reference/i18n/#overview-predefined, can you provide link in spec/on implementation which respect of handling this
noahziheng commentedon Jan 24, 2022
@alexander-akait
I found the description in WHATWG URL Spec at https://url.spec.whatwg.org/#authority-state.
If U+0040(@) used twice in the URL, the first one will convert to
%40and handled with authority params(username:password).The browser like Chrome, Firefox may handle
@@in URL specially. Maybe this case can be handled in webpack specially with a PR, if Node.js need compatible with previous versions?