host path prepended to urls generated with interpolated strings

[soychicka]

In the latest distribution (1.1.3), if you use this paraphrased example from the lesscss.org home page

@base-url: "http://assets.fnord.com";
.thing{
background-image: url("@{base-url}/images/bg.png");
}

the compiled result will be

.thing{
background-image: url("http://localhost:3000/path/to/stylesheets/http://assets.fnord.com/images/bg.png");
}

I don't know if this is a regression, as I've never had chance to use the string interpolation functionality before.

It looks like the string that is tested for the presence of a prefix around line 2270 isn't evaluated first, so the conditional isn't testing against the full url.

I see two possible solutions:

1. The easy way - modify the regex used to classify urls as relative/absolute, excluding any string that starts with '@{'
   I pulled it off locally - https://gist.github.com/1047106. Still, that's just a temporary fix until I can find out how to do it
2. The right way - use the regex in its current state to test the interpolated value of all urls. I'm not familiar enough with the code base, so I don't know the proper way to eval the string... if anyone could point me in the right direction, I'd be happy to fork and resolve this issue.

[jasonkeene]

I ran into the same issue.

@media_url: "/media";

// in some other scope

background: url("@{media_url}/images/sidebar_bg.png");

produced:

background: url("http://localhost:8000/media/less//media/images/sidebar_bg.png");

It basically prepended the path to the .less file to make the URL relative when it was intended to be absolute. This was only the case when I ran the compiler in browser and not from the command line.

Temporary Fix:

@media_url: "/media";

// in some other scope

background: ~"url(@{media_url}/images/sidebar_bg.png)";

[apneadiving]

@jasonkeene: thanks a bunch for your temporary fix!

[tarnfeld]

Any idea if this will be fixed any time soon? :)

[ochagnon]

Bump!

This break string interpolation as documented

[zachstronaut]

+1

This bug still exists in 1.2.0 when run in the browser.

[lggarrison]

+1

This bug still exists in 1.2.1 when run in the browser.

[danoc]

I'm having the issue in 1.3 as well. Thanks for the temporary fix, @jasonkeene!

[bclermont]

Me too!

[chanon]

This bug still exists in 1.3 when run in the browser.

[chanon]

A quick fix in less-1.3.0.js

// I commented out some lines marked with >> to fix the issue

tree.URL = function (val, paths) {
    if (val.data) {
        this.attrs = val;
    } else {
        /* >> just comment these lines out as we don't use any relative urls
        >> // Add the base path if the URL is relative and we are in the browser
        >> if (typeof(window) !== 'undefined' && !/^(?:https?:\/\/|file:\/\/|data:|\/)/.test(val.value) && paths.length > 0) {
        >>    val.value = paths[0] + (val.value.charAt(0) === '/' ? val.value.slice(1) : val.value);
        >> }
        >> */
        this.value = val;
        this.paths = paths;
    }
};

[johanbove]

@jasonkeene Just wanted to add my appreciation for providing a temporary solution to this issue: Thanks!

[WraithKenny]

If this is simply documented better, I'd consider it a feature ;-)

[WraithKenny]

It's worth pointing out that if you call the less parser on a source this isn't a problem at all. It's only a problem with the "automatic" browser version:
`

<script src="less.js" type="text/javascript"></script>`

[WraithKenny]

#807