In polymer 1.0, my elements that have links in the template dom are re-written to be relative to where the element is loaded rather than relative to the current browser location.
That is, if (in my element) I have:
<a href="/about">About us</a>
and the page is at http://widgets.com/ but the static content is served from http://cdn.com/path/to/content/, the link will point to http://cdn.com/about instead of http://widgets.com/about.
This appears to be occurring due to the urlResolver code:
function resolve(url, ownerDocument) {
if (url && url[0] === '#') {
return url;
}
var resolver = getUrlResolver(ownerDocument);
resolver.href = url;
return resolver.href || url;
}
function getUrlResolver(ownerDocument) {
return ownerDocument.__urlResolver || (ownerDocument.__urlResolver = ownerDocument.createElement('a'));
}
which is getting applied to my element.
A workaround at the moment is to inject the url via data-binding to a computed function, e.g.:
<a href="{{str('/about')}}">About us</a>
with
str: function(s) { return s; },
in my element... but that's just silly.
Bump. This is a big gotcha that's bitten me a few times.
Absolute paths should not be rewritten -- this should be fixed.
Ping @azakus / @tjsavage -- This has been a hot topic in the Slack channel today, It seems most people were not inclined to +1 this but, it does seem like a pretty important issue to address.
It definitely should not behave different when using computed binding like this:
<iron-ajax
url="/api/v1[[endpoint]]"
></iron-ajax
(this way it's resolved against the page)
Most helpful comment
Ping @azakus / @tjsavage -- This has been a hot topic in the Slack channel today, It seems most people were not inclined to +1 this but, it does seem like a pretty important issue to address.