Resolving URLs in c++

Was looking at how WebKit implements the WebShare API, and they have this nice method `completeURL(str)` [1] that resolved URLs relative to, I guess, the `Document` object (or whatever context is). So they can basically do this c++: 

```
    Optional<URL> url;
    if (!data.url.isEmpty()) {
        url = context.completeURL(data.url);
    }
```

Do we have an equivalent in Gecko? 

Right now, in Gecko, I'm having to do this:

```
  nsAutoString url;
  if (aData.mUrl.WasPassed()) {
    auto doc = mWindow->GetExtantDoc();
    if (!doc) {
      aRv.Throw(NS_ERROR_UNEXPECTED);
      return nullptr;
    }

    nsresult rv;
    nsCOMPtr<nsIURI> resolvedUri;
    rv = NS_NewURI(getter_AddRefs(resolvedUri), aData.mUrl.Value(), nullptr,
                   doc->GetDocumentURI(), nsContentUtils::GetIOService());
    if (NS_WARN_IF(NS_FAILED(rv))) {
      aRv.ThrowTypeError<MSG_INVALID_URL>(aData.mUrl.Value());
      return nullptr;
    }
    nsAutoCString utf8href;
    nsresult resolveURLRv = resolvedUri->GetSpec(utf8href);
    if (NS_FAILED(resolveURLRv)) {
      aRv.Throw(NS_ERROR_DOM_BAD_URI);
      return nullptr;
    }
    CopyUTF8toUTF16(utf8href, url);
  }
```

Which could maybe be wrapped into a nice utility function and placed somewhere? Or maybe something like that already exists? 

Also, having to use `nsIURI` feels kinda sad when we implement the URL Standard.... Can we use URL  somehow be used as a drop in replacement for nsIURI?  

https://github.com/WebKit/webkit/blob/master/Source/WebCore/page/Navigator.cpp#L123
0
mcaceres
7/12/2019 5:57:05 AM
mozilla.dev.platform 6529 articles. 0 followers. Post Follow

3 Replies
4 Views

Similar Articles

[PageSpeed] 8

On 7/12/19 1:57 AM, mcaceres@mozilla.com wrote:
> Do we have an equivalent in Gecko?

No, but it would no be a bad idea to add something...

> Right now, in Gecko, I'm having to do this:

Yeah, that's kinda ugly...

>      rv = NS_NewURI(getter_AddRefs(resolvedUri), aData.mUrl.Value(), nullptr,
>                     doc->GetDocumentURI(), nsContentUtils::GetIOService());

You could simplify this a bit by calling 
nsContentUtils::ewURIWithDocumentCharset, but that doesn't solve most of 
the issue.

Also, this clearly shows that our current setup is too easy to mess up: 
per spec this should be using the document's base URI, not the 
document's URI, as the base URI.

> Also, having to use `nsIURI` feels kinda sad when we implement the URL Standard.... Can we use URL  somehow be used as a drop in replacement for nsIURI?

Just to be clear, our URL Standard impl will swallow some of those 
errors this code is checking for and just return empty strings if they 
happen.  And of course it uses nsIURI under the hood.

Past that, it doesn't really have a nicer API (from C++) than nsIURI 
does, right?

-Boris
0
Boris
7/12/2019 7:02:49 AM
On Fri, Jul 12, 2019 at 9:05 AM Boris Zbarsky <bzbarsky@mit.edu> wrote:
> You could simplify this a bit by calling
> nsContentUtils::ewURIWithDocumentCharset, but that doesn't solve most of
> the issue.

>From the name that sounds somewhat wrong to me too. At least, for new
APIs I think we should always use UTF-8 as the encoding passed to the
URL parser and having now looked up
https://wicg.github.io/web-share/#share-method that is also what
should happen per the draft (Safari might actually do this wrong then,
I recommend adding a test).
0
Anne
7/12/2019 9:43:20 AM
On Thu, Jul 11, 2019 at 10:57:05PM -0700, mcaceres@mozilla.com wrote:
>Was looking at how WebKit implements the WebShare API, and they have this nice method `completeURL(str)` [1] that resolved URLs relative to, I guess, the `Document` object (or whatever context is). So they can basically do this c++:
....
>Right now, in Gecko, I'm having to do this:

Most of the overhead in this has nothing to do with resolving 
the URIs, so much as error checking. That said, there are a few 
ways to make it simpler. If you really need a UTF-16 string, you 
can do something like:

  nsAutoCString utf8URI;
  MOZ_TRY(doc->GetDocumentURI()->Resolve(aData.mUrl.Value()));

  NS_ConvertUTF8toUTF16 uri(utf8URI);

Though the general preference should be to keep URIs stored as 
nsIURIs rather than strings wherever possible, which means just:

  nsCOMPtr<nsIURI> uri;
  MOZ_TRY(NS_NewURI(getter_AddRefs(uri), aData.mUrl.Value(), 
                    doc->GetDocumentURI()));

There really isn't a need to pass a reference to the IO service 
to NS_NewURI anymore. Even if you happened to have a handy copy, 
the argument isn't even used anymore.
0
Kris
7/12/2019 7:35:11 PM
Reply: