CSSParserHelper.unescapeURL not following the css escape diagram

[shagkur]

As per https://drafts.csswg.org/css-syntax/#escape-diagram it's fully valid to have escape sequences within a URL string.
Example given:
`background-image: url('\2f home \2f data \2f imag.png')

[phax]

You are confusing escaping on the input stream and escaping in URLs - this is done based on different syntaxes.
The URL escaping is defined at https://www.w3.org/TR/css-syntax-3/#consume-url-token and it is okay.
The escaping of \xxxxxx is done directly in the jjtree file.

[shagkur]

I can't fully follow you 😞 Currently browser can handle such escaped values in the url() function by unescaping them according to the unescpae diagram. And i belive that's the "shortcoming" right now of the unescapeURL method. Not sure, if it'd make sense to have the "new" unescape logic extracted into a general unescape method to be able to use it for other CSS values to be unescaped.
Although this issue really references the current improper unescaping of the URL value.
So to me it seems your current approach in your alternate-fix-91 branch is fine.

[phax]

Well, there are 2 layers of unescaping when reading CSS. There is one top-level unescaping that can be used everywhere.
https://www.w3.org/TR/css-syntax-3/#input-preprocessing is used for all bytes on all areas. It's like a "filter InputStream". That should be handled on a different level of reading the CSS.
Additionally there is a special escaping for URLs - as defined by https://www.w3.org/TR/css-syntax-3/#consume-url-token and implemented in unescapeURL.

I will create some more tests to see what the exact status of the implementation is

[shagkur]

Ahh i see. However, for unescapeURL if a REVERSE SOLIDUS () is detected it is required to unescape the code point according to https://www.w3.org/TR/css-syntax-3/#consume-url-token. And this unescaping has to based on https://drafts.csswg.org/css-syntax/#escape-diagram (https://www.w3.org/TR/css-syntax-3/#consume-an-escaped-code-point). Therefore i'd say your implementation, in alternate-fix-91 for unescapeURL is correct. But i agree my assumption this mehod could be used for other CSS values, during the parsing/processing is probably wrong.

[phax]

I am trying a totally different approach. I am doing the unescaping at the point where the stream is read (in class CSSCharStream). This however interferes with a lot of existing tests (and IE hacks like \0 or \9), which further complicates the process. So I am on it, but give me some time.

[shagkur]

Sure, no worries. Meanwhile we've a quick-fix hack on our side to fix this \2f escape issue. But thanks alot for the update. Looking forward to new release then 😄

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.