Bug 266287 – @supports reporting true for `animation-timeline: scroll()` when using CSS nesting

• Status: RESOLVED
• Resolution: DUPLICATE
• Component: CSS

[Adam Argyle]

Created attachment 468996 [details]
Safari devtools open with the problem element selected. Devtools appears to be trying to apply an animation-timeline() because the @supports query is reporting true

Safari is trying to apply an `animation-timeline(`) because the @supports query is reporting support. This bug showed up as soon as I shipped native nesting on my blog. 

Link to post where the screenshot was taken:
https://nerdy.dev/using-open-props-with-nextjs-and-the-brand-new-react-style-library-stylex

[Antoine Quint]

Thanks for the report Adam. What version of Safari / macOS version is this?

[Radar WebKit Bug Importer]

<rdar://problem/119570809>

[Adam Argyle]

I noticed it in 17.1 and tested 17.4 TP and found the same issue in both
macOS 14.1 (23B74)

[Antoine Quint]

Interestingly `CSS.supports("animation-timeline", "scroll()")` is false.

[Antoine Quint]

To reproduce:

1. load https://nerdy.dev/using-open-props-with-nextjs-and-the-brand-new-react-style-library-stylex
2. cmd+click on the small photo on the top left of the title and choose "Inspect Element"
3. in the result Web Inspector, you should have an <img> element selected and scrolling down the style panel should reveal the issue.

The erroneous @support (animation-timeline: scroll()) is combined with cascade layers and nesting here, and it looks like it's the combination of those things that is causing trouble because a simple test with just @suppors reveal no such problem:

<style>
body { background-color: green }
@supports (animation-timeline: scroll()) {
    body { background-color: red }
}
</style>

This yields a green body in Safari and STP 184 (and red in Chrome where scroll-driven animations are supported).

[Antoine Quint]

A simple test case with nesting reproduces the issue though:

<style>
body {
    background-color: green;
    @supports (animation-timeline: scroll()) {
        background-color: red;
    }
}
</style>

So it's likely an issue with properties gated behind runtime flags and nesting.

[Tim Nguyen (:ntim)]

This testcase also triggers an assertion on debug builds:

ASSERTION FAILED: topContext().m_parsedProperties.isEmpty()
/Volumes/Data/Code/Safari/OpenSource/Source/WebCore/css/parser/CSSParserImpl.cpp(254) : bool WebCore::CSSParserImpl::supportsDeclaration(CSSParserTokenRange &)
1   0x138ec3b20 WTFCrash
2   0x2832d8254 WTFCrashWithInfo(int, char const*, char const*, int)
3   0x28396c708 WebCore::CSSParserImpl::supportsDeclaration(WebCore::CSSParserTokenRange&)
4   0x283a6657c WebCore::CSSSupportsParser::consumeSupportsFeatureOrGeneralEnclosed(WebCore::CSSParserTokenRange&)
5   0x283a66850 WebCore::CSSSupportsParser::consumeConditionInParenthesis(WebCore::CSSParserTokenRange&, WebCore::CSSParserTokenType)
6   0x283a66164 WebCore::CSSSupportsParser::consumeCondition(WebCore::CSSParserTokenRange)
7   0x283a65fc4 WebCore::CSSSupportsParser::supportsCondition(WebCore::CSSParserTokenRange, WebCore::CSSParserImpl&, WebCore::CSSSupportsParser::SupportsParsingMode, WebCore::CSSParserEnum::IsNestedContext)
8   0x28396df2c WebCore::CSSParserImpl::consumeSupportsRule(WebCore::CSSParserTokenRange, WebCore::CSSParserTokenRange)
9   0x28396b2c0 WebCore::CSSParserImpl::consumeAtRule(WebCore::CSSParserTokenRange&, WebCore::CSSParserImpl::AllowedRulesType)
10  0x283974b14 WebCore::CSSParserImpl::consumeBlockContent(WebCore::CSSParserTokenRange, WebCore::StyleRuleType, WebCore::CSSParserImpl::OnlyDeclarations, WebCore::CSSParserImpl::ParsingStyleDeclarationsInRuleList)
11  0x283975284 WebCore::CSSParserImpl::consumeStyleBlock(WebCore::CSSParserTokenRange, WebCore::StyleRuleType, WebCore::CSSParserImpl::ParsingStyleDeclarationsInRuleList)
12  0x283988dfc WebCore::CSSParserImpl::consumeStyleRule(WebCore::CSSParserTokenRange, WebCore::CSSParserTokenRange)::$_1::operator()() const
13  0x2839746e4 void WebCore::CSSParserImpl::runInNewNestingContext<WebCore::CSSParserImpl::consumeStyleRule(WebCore::CSSParserTokenRange, WebCore::CSSParserTokenRange)::$_1>(WebCore::CSSParserImpl::consumeStyleRule(WebCore::CSSParserTokenRange, WebCore::CSSParserTokenRange)::$_1&&)

[Matthieu Dubet]

This is the same underlying bug as : https://bugs.webkit.org/show_bug.cgi?id=259752

[Alexey Proskuryakov]

That one is now fixed, is this fixed too?

[Tim Nguyen (:ntim)]

*** This bug has been marked as a duplicate of bug 259752 ***