Re: Resolving URLs in c++
On Thu, Jul 11, 2019 at 10:57:05PM -0700, mcace...@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 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. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Resolving URLs in c++
On Fri, Jul 12, 2019 at 9:05 AM Boris Zbarsky 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). ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Resolving URLs in c++
On 7/12/19 1:57 AM, mcace...@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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
