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?

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.

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