39363 2010-05-19 09:22:56 -0700 Fix url tokenization in CSS 2022-07-21 17:20:04 -0700 1 1 1 Unclassified WebKit CSS 528+ (Nightly build) Mac OS X 10.5 RESOLVED CONFIGURATION CHANGED http://test.csswg.org/source/contributors/mozilla/incoming/reftests/bugs/invalid-url-handling.xht P2 Normal --- 1 simon.fraser glenn ahmad.saleem792 ap benjamin bfulgham glenn rniwa seikwon.kim oldest_to_newest 227852 0 simon.fraser 2010-05-19 09:22:56 -0700 We fail a bunch of the URL tests in this testcase: http://test.csswg.org/source/contributors/mozilla/incoming/reftests/bugs/invalid-url-handling.xht 227854 1 simon.fraser 2010-05-19 09:24:23 -0700 Note that not all of the tests in that file are necessarily valid tests. 227888 2 ap 2010-05-19 10:51:52 -0700 See also: bug 28885. 733906 3 benjamin 2012-10-03 12:10:31 -0700 I suggest to make a reduction for fast/url, and upload it with failing results. For info, there is now a working version (albeit incomplete) of WTFRL in the tree. 733927 4 benjamin 2012-10-03 12:27:03 -0700 Looking at the failing cases, it does not looks like a URL parsing error. All the invalid URL are considered invalid by KURL. The tests fail due to the way we handle some invalid input in CSS. Examples: Test 3: #three { background-color: green; } #foo { background: url(foo"bar) } #three { background-color: red; } ->The test expect the last #three to be ignored due to the error on the second line. I don't see why that test is correct. Test 4: /* not a URI token; the unterminated string ends at end of line */ #foo { background: url(foo"bar) } ) } #four { background-color: green; } ->The URL is invalid, it is the CSS parsing that is incomplete. etc. 734260 5 glenn 2012-10-03 17:39:45 -0700 (In reply to comment #4) > Looking at the failing cases, it does not looks like a URL parsing error. All the invalid URL are considered invalid by KURL. > > The tests fail due to the way we handle some invalid input in CSS. > > Examples: > > Test 3: > #three { background-color: green; } > #foo { background: url(foo"bar) } > #three { background-color: red; } > ->The test expect the last #three to be ignored due to the error on the second line. I don't see why that test is correct. The second line should tokenize as follows (by CSS2.1 lexer rules): ... BADURL(foo) BADSTRING(bar ) }) causing the third line to appear as a continuation of the declaration started in the second line, and thus producing a MalformedDeclaration recovery, in which case the background-color: red is ignored At present, WK doesn't tokenize in this manner, but instead returns FUNCTION(url) IDENT(foo) " IDENT(bar) ... which eventually matches: function: FUNCTION maybe_space error since the " token is not a valid operator for combining terms in an expression. Consequently, WK finishes the declaration on the second line without continuing to third line, and the background-color red is applied. > > Test 4: > /* not a URI token; the unterminated string ends at end of line */ > #foo { background: url(foo"bar) } > ) } > #four { background-color: green; } > ->The URL is invalid, it is the CSS parsing that is incomplete. The same logic applies as above, but here the ") }" on third line causes the fourth line to be ignored (in WK) as a MalformedStatement. If WK had consumed the string as BADSTRING(bar ) }), then the declaration of second line would complete on the third line's }, in which case the fourth line would parse. > > etc. 734265 6 glenn 2012-10-03 17:49:47 -0700 (In reply to comment #3) > I suggest to make a reduction for fast/url, and upload it with failing results. Working on it now. > For info, there is now a working version (albeit incomplete) of WTFRL in the tree. I guess you mean WTFURL, i.e., WTF/wtf/url/api, yes? 734274 7 benjamin 2012-10-03 17:56:19 -0700 > (In reply to comment #3) > > I suggest to make a reduction for fast/url, and upload it with failing results. > > Working on it now. > > > For info, there is now a working version (albeit incomplete) of WTFRL in the tree. > > I guess you mean WTFURL, i.e., WTF/wtf/url/api, yes? Yep, WTFURL. After you last comment, I doubt this require tests for URLs. It looks like the CSS tokenizer is the issue here. Isn't it? 734279 8 glenn 2012-10-03 17:59:01 -0700 (In reply to comment #7) > > (In reply to comment #3) > > > I suggest to make a reduction for fast/url, and upload it with failing results. > > > > Working on it now. > > > > > For info, there is now a working version (albeit incomplete) of WTFRL in the tree. > > > > I guess you mean WTFURL, i.e., WTF/wtf/url/api, yes? > > Yep, WTFURL. > > After you last comment, I doubt this require tests for URLs. It looks like the CSS tokenizer is the issue here. Isn't it? correct 1885495 9 ahmad.saleem792 2022-07-20 17:00:12 -0700 I took a test case from Mozilla Firefox Source Code repo from below link: https://searchfox.org/mozilla-central/source/layout/reftests/css-parsing/invalid-url-handling.xhtml and turned it into following JSFiddle: https://jsfiddle.net/3a9keLtc/show Based on above JSFiddle, Safari 15.6 on macOS 12.5 passes all test and have green text and it is same across other browsers (Chrome Canary 105 and Firefox Nightly 104) as well. Is something else needed to be fixed here? Thanks! 1885883 10 rniwa 2022-07-21 17:20:04 -0700 Yeah, I'm sure this got fixed when we copied Blink's CSS parser.