1848511 - Failing URL WPTs due to javascript: URLs

Status: ASSIGNED

(Core :: Networking, defect, P2)

Description

[Thomas Wisniewski [:twisniewski]]

There are a number of WPTs failing because we are treating all javascript: URLs as SimpleURLs, which do not support username/password/etc. A very simple way to fix this seems to be to just adjust nsNetUtil::NS_NewURI as follows:

  if (scheme.EqualsLiteral("javascript")) {
    if (aSpec.Find("javascript:/") != 0) {
      return nsJSProtocolHandler::CreateNewURI(aSpec, aCharset, aBaseURI, aURI);
    }
    auto mut = NS_MutateURI(new DefaultURI::Mutator());
    if (aBaseURI) {
      nsAutoCString newSpec;
      rv = aBaseURI->Resolve(aSpec, newSpec);
      NS_ENSURE_SUCCESS(rv, rv);
      mut.SetSpec(newSpec);
    } else {
      mut.SetSpec(aSpec);
    }
    return mut.Finalize(aURI);
  }

This will pass all of the related tests with a couple of exceptions. One is caused by bug 1553105, as we are expected to return a null origin for the JS URLs. A similarly simple fix for that is to adjust nsContentUtils::GetWebExposedOriginSerialization as follows, but I'm not sure if that's the right solution given the conversation in the parent bug:

   nsCOMPtr<nsIURI> uri = NS_GetInnermostURI(aURI);
   NS_ENSURE_TRUE(uri, NS_ERROR_UNEXPECTED);
 
+  // https://url.spec.whatwg.org/#concept-url-origin
+  // if not blob, ftp, http, https, ws, wss, or file,
+  // return a new opaque origin (null)
+  if (!aURI->SchemeIs("file") && !aURI->SchemeIs("ftp") &&
+      !aURI->SchemeIs("http") && !aURI->SchemeIs("https") &&
+      !aURI->SchemeIs("ws") && !aURI->SchemeIs("wss")) {
+    aOrigin.AssignLiteral("null");
+    return NS_OK;
+  }
+

The other remaining failure will be tests checking this URL form:

Parsing: <javascript://:443> without base

But I have a suspicion that may start working when we update the DefaultURI crate, plus we're already failing it.

What do you think, Valentin?

Comment 1

[Valentin Gosu [:valentin] (he/him)]

This is definitely an option we could take.
Once we get bug 1603699 landed, nsJSURI is probably something we can easily migrate to defaultURI too.

Comment 2

[Thomas Wisniewski [:twisniewski]]

Ok, then let's wait for bug 1603699, there's no real rush here.

Comment 3

[Thomas Wisniewski [:twisniewski]]

Since bug 1603699 has recently landed, I'm working on a patch to use DefaultURI instead of SimpleURI for JS URLs. This will let us avoid having to do the extra checks that the patch in bug 1722328 just added, and also clean the related code up a little in general. We'll pass the following URL WPTs with this change:

• url/a-element-xhtml.xhtml?include=javascript
• url/a-element.html?include=javascript
• url/url-constructor.any.worker.html?include=javascript
• url/url-constructor.any.html?include=javascript
• url/url-setters-a-area.window.html?include=javascript
• url/url-setters.any.html?include=javascript
• url/url-setters.any.worker.html?include=javascript
• url/javascript-urls.window.js *

• all but one of the sub-tests here will now pass, rather than the whole set timing out. The one remaining failure is also not passing in Blink or WebKit at the moment (javascript: URL without an opaque path)

Comment 4

[Thomas Wisniewski [:twisniewski]]

https://treeherder.mozilla.org/jobs?repo=try&revision=47703c4584d42700a637caea34b366fb4a356295

Comment 5

[Thomas Wisniewski [:twisniewski]]

Attachment: Bug 1848511 - base nsJSURI and its mutator on DefaultURI rather than SimpleURI; r?edgul