Could you provide a standalone test case that reproduces this issue (for example on jsbin.com/jsfiddle.net, or upload a html file)? I can't manage to repro this on 50.0.2661.104.

Also if possible, could you test newer Chrome versions? The current stable version of Chrome is now M51.

Thanks!

good day.

I have already made a simple example jsFiddle reproducing the same error:

https://jsfiddle.net/cgalvist/emmcbwzn/15/

I tried to add an icon with an absolute url, but if it works in Chrome. It seems that the problem is with a relative url.

Right now I am using Chromium. 50.0.2661.102 version in Ubuntu 16.04 64 bits.

As already mentioned, if it works in Firefox 46.0.1 on Ubuntu 16.04 64 bits.

Right now I can not update chromium, but later performed the same test with the updated browser.

Thanks, I can repro this on M51.

The CSSVariableResolver just creates a new CSSParserContext so it can't resolve URLs.

https://jsfiddle.net/suj05a9z/1/

tentatively assigning to myself

ok, thanks for your attention

 Issue 637072  has been merged into this issue.

As per the duped bug, this also applies to @apply rules and protocol-relative urls (i.e. without the http(s)).

Tab, if we have --a:url(a.png) and background-image:var(--a) in separate sheets, which sheet should we use the base URL from?

The behavior that falls out most obviously is to use the "background-image" sheet - the url() isn't interpreted as a url until it's substituted.

This might change if the custom property was declared to have a <url> type, as we'd then be able to resolve it as a url immediately in the custom property.

I'm unsure which behavior is better, but I suspect it would be best to have a consistent behavior between the two cases.

(Just lurking on this issue, apologies for the intrusion.)

Resolving URL types relative to the declaration stylesheet seems preferable.

a.css
--a:a.png /* just a string at this point */

b.css
--b:url(b.png) /* resolve relative to b.css */

c.css
--background-image:url(var(--a)) /* now resolve relative to c.css */
--background-image:var(--b) /* already resolved relative to b.css */

$0.02 as a user/fan of this feature :)

Yeah, I agree that's probably the best choice, it just means having to actually look for urls and carry around side-channel information about them.  We can't *actually* resolve the url at declaration time, because we have no idea if it's going to be used in a CSS property at all; we'd have to instead just annotate the url() function we parsed with a hidden "resolved url", and use that *if* it ends up being put into a CSS property that expects a URL.

That's a lot more complicated than what the spec mandates currently, which is that the value of a custom property is just an uninterpreted token stream, which only gains meaning after substitution into a real property.

Also, more complex case:

a.css
--a: "a.png";

b.css
--b: url(var(--a));

c.css
background-image: var(--b); /* resolved according to a, b, or c? */

 Issue 645309  has been merged into this issue.

 Issue 652044  has been merged into this issue.

 Issue 660664  has been merged into this issue.

 Issue 668364  has been merged into this issue.

We resolved in today's CSS call [1] that URLs in custom properties are not treated specially, and resolve when substituted in a non-custom property, with the origin of that stylesheet (c.css in Tab's example in Comment 13). Perhaps this bug can be fixed now?

[1]: https://github.com/w3c/csswg-drafts/issues/757

Unassigning because I'm not working on this right now, but yes we should fix it :-)

I think this will be easy to implement after https://codereview.chromium.org/2616093003/ lands, we'd just need to add a pointer to the parser context in probably the CSSVariableData (since registered properties might need these for <image>/<url> types too).

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/9f693fb8bdcda52ef30230ff57592a9736707dff

commit 9f693fb8bdcda52ef30230ff57592a9736707dff
Author: fs <fs@opera.com>
Date: Mon Jan 16 13:22:07 2017

Provide a CSSParserContext to CSSSyntaxDescriptor

Add a CSSParserContext* argument to CSSSyntaxDescriptor::parse to allow
CSSValues to be resolve against a proper parser context, and resolve
relative URLs and other sourcing sensitive data.
Provide parser contexts as available on call-sites, or use the
strictCSSParserContext() if none is available. Move the TODO up the
callstack as needed.

BUG= 618165 

Review-Url: https://codereview.chromium.org/2632083002
Cr-Commit-Position: refs/heads/master@{#443882}

[modify] https://crrev.com/9f693fb8bdcda52ef30230ff57592a9736707dff/third_party/WebKit/Source/core/css/CSSSyntaxDescriptor.cpp
[modify] https://crrev.com/9f693fb8bdcda52ef30230ff57592a9736707dff/third_party/WebKit/Source/core/css/CSSSyntaxDescriptor.h
[modify] https://crrev.com/9f693fb8bdcda52ef30230ff57592a9736707dff/third_party/WebKit/Source/core/css/CSSVariableData.cpp
[modify] https://crrev.com/9f693fb8bdcda52ef30230ff57592a9736707dff/third_party/WebKit/Source/core/css/PropertyRegistration.cpp
[modify] https://crrev.com/9f693fb8bdcda52ef30230ff57592a9736707dff/third_party/WebKit/Source/core/css/parser/CSSParserImpl.cpp

As far as I see, css variable urls are properly resolved on tip-of-tree. Should this be closed?

Hey fs@, does your CL completely fix this? If so, could you please close this bug? Thanks!

It was just a very small step in the general direction of a fix (I think), while working on a somewhat related issue.

My guess would be that https://codereview.chromium.org/2718273002 (for  issue 270059 ) may have made some cases here appear fixed (it most certainly will not be correct for all cases IIUC.)

Thanks for the response, fs! 

 Issue 702121  has been merged into this issue.

Fixed by https://crrev.com/a3079e2f1ea9974caebcdebd00c1c33dbaa662e0.

is there any workaround for those of us who cannot update browsers yet?