1978288 - javascript://example.com URI in new URL() should return the hostname

Status: RESOLVED DUPLICATE of bug 1848511

(Core :: Networking, defect, P2)

Description

[Renwa]

Steps to reproduce:

Both Chrome and Safari returns the hostname as (example.com) but Firefox returns null

new URL('javascript://example.com/').hostname

Actual results:

"null"

Expected results:

example.com

Comment 1

[Francesco Lodolo [:flod]]

Not sure javascript://example.com is valid, but moving to JS for triaging.

Comment 2

[edgul]

It's been a while since working on Bug 1722328, but it looks like we are still failing some WPTs with hostnames in them.

I wouldn't expect Bug 1722328 to change this fact because we are only using a host-aware parser to check for validity.
We continue on to use a simple parser to populate the URL fields in our memory structure, and this simple parser doesn't support hostnames.

The WPTs suggest this should be possible.
MDN doesn't mention hostnames https://developer.mozilla.org/en-US/docs/Web/URI/Reference/Schemes/javascript.
And a quick scan of the specs (RFC 3986 and URL Parser) don't readily answer the validity question.

Tom, do you know? Or are you able to provide additional context?
I recall there being some concerns surrounding spec ambiguity that block our ability to move forward with javascript scheme fixes. Would this bug fall into that category?

Comment 3

[Thomas Wisniewski [:twisniewski]]

Sorry, it's been long enough that I'm no longer sure.

Comment 4

[Renwa]

Chrome started supporting javascript urls in v130, this might be useful just leaving it here. https://docs.google.com/document/d/1LjxHl32fE4tCKugrK_PIso7mfXQVEeoD1wSnX2y0ZU8/edit?usp=drivesdk&resourcekey=0-d1gP4X2sG7GPl9mlTeptIA

Comment 5

[Hackbot]

Answering comment 2: yes, the host in javascript://example.com/ is meant to be parsed. javascript: is not a special scheme, so the URL parser goes scheme -> "path or authority state", and a leading // moves it into "authority state" — the same route data: and mailto: take. There is no javascript-specific carve-out. WPT's urltestdata.json spells out the expectations:

• javascript://example.com:8080/pathname?search#hash -> hostname example.com, port 8080, pathname /pathname, origin null
• javascript://test/a/../b -> javascript://test/b (non-opaque path, so dot-segments collapse)
• javascript://:443, javascript://test:test, javascript://[:1] -> parse failure

We already get the three failure cases right — that's the DefaultURI validity check added in bug 1722328. What's missing is exactly what comment 2 describes: nsSimpleURI discards the authority the host-aware parser found.

This is already tracked in bug 1848511, which has a patch: D197437, "base nsJSURI and its mutator on DefaultURI rather than SimpleURI". It unsets precisely the WPT expectations linked in comment 2. Suggest duping this bug to bug 1848511 rather than tracking it separately.

For context on why that patch stalled (it isn't just lack of attention):

• robwu asked to hold pending the spec discussion at https://github.com/whatwg/url/issues/385, noting javascript: was deliberately excluded from the Interop 2023 URL scope as too risky.
• It changes which script a javascript: URL executes. JSURLInputStream::Init takes the script text from GetPathQueryRef() (dom/jsurl/nsJSProtocolHandler.cpp), so javascript://host/foo would start running /foo instead of //host/foo. That is what the "javascript: URL without an opaque path" WPT covers, and it needs a security look.
• MatchPattern.cpp has been substantially rewritten since the patch was posted, so it needs a rebase in any case.

---

If you'd like to provide feedback on this comment, please use the 👍 or 👎 reaction.