*TL;DR: the `loadURI` method on nsIWebNavigation (often accessed on
docshell objects) and CanonicalBrowsingContext now take an nsIURI as
their first parameter.* Despite their name, they used to take strings
and run "fixup" on them to try to get an nsIURI.
If you land a patch that passes a string instead, that won't compile
(for C++ callers) or it will throw a runtime exception (JS callers:
NS_ERROR_XPC_BAD_CONVERT_JS: Could not convert JavaScript argument arg 0
[nsIWebNavigation.loadURI]). I apologize for any patch bitrot this may
cause.
You can either pass an nsIURI instead (recommended), or if you are
getting arbitrary input as strings, can call `fixupAndLoadURIString`
instead (which takes a string and will use nsIURIFixup to parse/guess at
what the URI should be).
(Note: for browser mochitests, you can use
BrowserTestUtils.loadURIString which still takes a string.)
Note that Emilio also recently landed an API addition
<https://bugzilla.mozilla.org/show_bug.cgi?id=1812496> that allows you
to get an nsIURI directly if you have a DOM URL, and vice versa, without
copying and reparsing the underlying string, which might help depending
on your context.
These same changes have also been made to the identically-named APIs
exposed on the `browser` custom element and on the `gBrowser`/tabbrowser
JS wrappers.
I intend to file follow-ups to convert more callsites to `loadURI`
(instead of `fixupAndLoadURIString`) and directly pass nsIURIs. This
will avoid repeatedly copying and reparsing the same URL (which can be
expensive, especially for large data URIs) and makes the behaviour more
predictable. Quite often consumers already have/need an nsIURI instance
(to start a speculative connection, or to pass to places APIs, or to
decide what process the browsing context needs to switch to, or...) and
so making sure that that URI corresponds to what is being loaded should
help both performance and reliability going forward.
Thanks,
Gijs
--
You received this message because you are subscribed to the Google Groups
"[email protected]" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/a/mozilla.org/d/msgid/dev-platform/84c53cf4-126b-f5e0-c677-f634359b4097%40mozilla.com.
