urlResolve() does not parse content:// URL's correctly in Chrome

[antoinevg]

When resolving the following URL in Chrome:

"content://io.trigger.forgeac179a2a726911e5bb021231392b77b0/tab/chats/3

the urlResolve() function will return:

{
    "href": "content://io.trigger.forgeac179a2a726911e5bb021231392b77b0/tab/chats/3", 
    "protocol": "content:", 
    "host": "", 
    "search": "", 
    "hash": "", 
    "hostname": "", 
    "port": "", 
    "pathname": "//io.trigger.forgeac179a2a726911e5bb021231392b77b0/tab/chats/3"
}

Calling urlResolve() from Safari or the NodeJS environment will return the far saner:

{
    "href": "content://io.trigger.forgeac179a2a726911e5bb021231392b77b0/tab/chats/3", 
    "protocol": "content", 
    "host": "io.trigger.forgeac179a2a726911e5bb021231392b77b0", 
    "search": "", 
    "hash": "", 
    "hostname": "io.trigger.forgeac179a2a726911e5bb021231392b77b0", 
    "port": "", 
    "pathname": "/tab/chats/3"
}

This, of course, ends up breaking navigation in Angular.

Investigation revealed that the problem is rooted in the way Chrome parses URL's assigned to DOM anchor nodes.

One way to fix this would be to explicitly check for content URL's that may not have been parsed correctly and normalise as follows:

function urlResolve(url) {
    var href = url;

    if (msie) {
        // Normalize before parse.  Refer Implementation Notes on why this is
        // done in two steps on IE.
        urlParsingNode.setAttribute('href', href);
        href = urlParsingNode.href;
    }

    urlParsingNode.setAttribute('href', href);

    // -- begin new code ----
    var normalizeContentURL = false;
    if (urlParsingNode.host.length === 0 && urlParsingNode.hostname.length === 0
        && urlParsingNode.protocol.indexOf("content") === 0) {
        // Normalize url and replace protocol as Chrome url parser does not parse
        // host, hostname & pathname correctly for content:// URL's
        normalizeContentURL = true;
        url = urlParsingNode.href;
        urlParsingNode.setAttribute('href', url.replace("content://", "http://"));
    }
    // -- end new code ----

    // urlParsingNode provides the UrlUtils interface - http://url.spec.whatwg.org/#urlutils
    var ret = {
        href: urlParsingNode.href,
        protocol: urlParsingNode.protocol ? urlParsingNode.protocol.replace(/:$/, '') : '',
        host: urlParsingNode.host,
        search: urlParsingNode.search ? urlParsingNode.search.replace(/^\?/, '') : '',
        hash: urlParsingNode.hash ? urlParsingNode.hash.replace(/^#/, '') : '',
        hostname: urlParsingNode.hostname,
        port: urlParsingNode.port,
        pathname: (urlParsingNode.pathname.charAt(0) === '/')
                ? urlParsingNode.pathname
                : '/' + urlParsingNode.pathname
    };

    // -- begin new code ----
    if (normalizeContentURL) {
        // restore protocol if necessary
        ret.protocol = "content";
        ret.href = url;
    }
    // -- end new code ----

    return ret;
}

Thoughts?

[Narretz]

Isn't this a bug in Chrome and should preferably be fixed there? And in what context do content urls exist? It just feels weird to special case content like this.

[antoinevg]

Tx Narretz!

I agree with you that this ultimately needs to be sorted out in Chrome but it does mean that, for a very long time, we're still going to be stuck with the broken behaviour on older versions of Chrome. :-/

I'm not terribly by excited by the idea of special-casing content:// either, it's really smelly and I'm sure there's a better way to handle this!

re: some context on content:// URL's

These are the URL's used by the Android target of the Trigger.io hybrid app runtime to serve & access local content.

The format is:

content://<package_name>/<path-to-resource>

The reason Trigger.io uses content: rather than file: is primarily to allow the serving of other app resources in addition to the files available in the app's local sandbox.

[dwatling]

My team is running into a similar issue. We're serving up our AngularJS application in a WebView via a ContentProvider, however the problem we're seeing is when routes are used. Our application's initial URL is: "content://embedded.resources/www/index.html#login". The result of urlResolve is:

hash: ""
host: ""
hostname: ""
href: "content://embedded.resources/login"
pathname: "//embedded.resources/login"
port: ""
protocol: "content"
search: ""

The pathname is incorrect and should just be "/login". antoinevg's fix did not work for my team's case. The following code change worked:

var pathname = urlParsingNode.pathname;

if (pathname.indexOf("//") === 0) {
  pathname = pathname.substring(pathname.indexOf("/", 2));
} else {
  pathname = (pathname.charAt(0) === '/')
    ? urlParsingNode.pathname
    : '/' + urlParsingNode.pathname;
}

Then the 'pathname' variable is passed back in the hash.

I do agree that the true fix lies in Chrome. However, I also agree with antoinevg that once the fix is in place we still need a fallback to support users on older versions of Chrome. Ultimately, that is in AngularJS.