Bug 190039 – Registered custom properties should support syntax parameter for <length> and *

• Component: Layout and Rendering
• Status: RESOLVED FIXED

[Justin Michaud]

Registered custom properties should support syntax parameter for <length> and *. In addition, these values should be correctly substituted for inherited properties, and cycles caused by relative units should be correctly identified.

[Justin Michaud]

Created attachment 351937 [details]
patch

This is a WIP patch to refactor the code to properly handle dependencies. It is not ready yet, but I was hoping to get some preliminary feedback. I am also hoping to see what this breaks in ews.

TODOs:
- Add tests for dependency resolution between fonts
- Handle root dependencies
- Add the crashing test case (this patch fixes it). See the bug this blocks.
- Fix the current web platform tests

[EWS Watchlist]

Attachment 351937 [details] did not pass style-queue:


ERROR: Source/WebCore/css/parser/CSSParser.cpp:217:  Weird number of spaces at line-start.  Are you using a 4-space indent?  [whitespace/indent] [3]
ERROR: Source/WebCore/css/StyleResolver.cpp:2282:  Multi line control clauses should use braces.  [whitespace/braces] [4]
ERROR: Source/WebCore/rendering/style/StyleCustomPropertyData.h:57:  Should have a space between // and comment  [whitespace/comments] [4]
ERROR: Source/WebCore/css/CSSVariableData.h:57:  The parameter name "style" adds no information, so it should be removed.  [readability/parameter_name] [5]
ERROR: Source/WebCore/css/CSSCustomPropertyValue.h:34:  Alphabetical sorting problem.  [build/include_order] [4]
ERROR: Source/WebCore/css/CSSCustomPropertyValue.h:105:  Weird number of spaces at line-start.  Are you using a 4-space indent?  [whitespace/indent] [3]
ERROR: Source/WebCore/css/CSSCustomPropertyValue.cpp:58:  Weird number of spaces at line-start.  Are you using a 4-space indent?  [whitespace/indent] [3]
ERROR: Source/WebCore/css/CSSVariableReferenceValue.h:33:  Alphabetical sorting problem.  [build/include_order] [4]
ERROR: Source/WebCore/css/CSSVariableReferenceValue.h:33:  Alphabetical sorting problem.  [build/include_order] [4]
ERROR: Source/WebCore/css/CSSVariableReferenceValue.cpp:33:  Alphabetical sorting problem.  [build/include_order] [4]
ERROR: Source/WebCore/css/CSSVariableReferenceValue.cpp:106:  One line control clauses should not use braces.  [whitespace/braces] [4]
Total errors found: 11 in 20 files


If any of these errors are false positives, please file a bug against check-webkit-style.

[EWS Watchlist]

Comment on attachment 351937 [details]
patch

Attachment 351937 [details] did not pass win-ews (win):
Output: https://webkit-queues.webkit.org/results/9519805

New failing tests:
fast/css/variables/env/safe-area-inset-env-cannot-override.html
fast/css/variables/env/safe-area-inset-env-zero.html
fast/css/variables/custom-property-dynamic-update.html

[EWS Watchlist]

Created attachment 351982 [details]
Archive of layout-test-results from ews206 for win-future

The attached test failures were seen while running run-webkit-tests on the win-ews.
Bot: ews206  Port: win-future  Platform: CYGWIN_NT-6.1-2.9.0-0.318-5-3-x86_64-64bit

[Justin Michaud]

Created attachment 352251 [details]
Patch

[Justin Michaud]

Comment on attachment 352251 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=352251&action=review

This is a massive patch, sorry about that Antti. This patch fixes a bunch of bugs caused by the refactoring, as well as a few from the initial implementation. I am sure it is going to require at least a few more iterations, but hopefully it can pave the way for future refactoring as well as other custom property types. If you see anything that can be spun off into a separate patch, let me know. I couldn't find anything that would split nicely.

> Source/WebCore/css/CSSStyleDeclaration.h:63
> +    virtual ExceptionOr<void> setPropertyWebkit1(const String& propertyName, const String& value, const String& priority) = 0;

Not sure what to do about this. I couldn't get a document from the webkit 1 code. It is script wrappable, but everything is null if you try to do [frameElement setProperty:...] from mini browser.

> Source/WebCore/css/CSSVariableData.h:64
>      // FIXME-NEWPARSER: We want to cache StyleProperties once we support @apply.

Not sure what this means

> Source/WebCore/css/StyleResolver.cpp:432
> +    ApplyCascadedPropertyState applyState { this, &cascade, &result, { }, { }, { }, { } };

These changes seem likely to break something or cause a perf regression. I am not sure how to test this.

> Source/WebCore/css/parser/CSSParser.cpp:247
> +    // FIXME handle REM cycles.

I will make a separate bug for this if it gets merged.

> Source/WebCore/css/parser/CSSPropertyParser.cpp:4282
> +bool CSSPropertyParser::canParseTypedCustomPropertyValue(const String& syntax)

This behavior matches chrome, but it is not in the spec. Inline styles seem to reject obviously bad values, but accept anything with var in it. See the inline.html test case, but I think this deserves a spec bug.

> Source/WebCore/css/parser/CSSPropertyParser.h:54
> +    CSSPropertyParser(const CSSParserTokenRange&, const CSSParserContext&, Vector<CSSProperty, 256>*, bool consumeWhitespace = true);

This was needed to fix a regression caused by the extra parsing for unresolved custom properties. I added a test, so it shouldn't cause any regressions.

> LayoutTests/css-custom-properties-api/crash.html:1
> +<!DOCTYPE html><!-- webkit-test-runner [ experimental:CSSCustomPropertiesAndValuesEnabled=true ] -->

See https://bugs.webkit.org/show_bug.cgi?id=184542

> LayoutTests/imported/w3c/web-platform-tests/css/css-properties-values-api/register-property-syntax-parsing-expected.txt:88
> +FAIL syntax:'*', initialValue:'initial' is invalid assert_throws: function "() => CSS.registerProperty({name: name, syntax: syntax, initialValue: initialValue, inherits: false})" did not throw

I think this can go in a separate bug

[Antti Koivisto]

Comment on attachment 352251 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=352251&action=review

>> Source/WebCore/css/CSSStyleDeclaration.h:63
>> +    virtual ExceptionOr<void> setPropertyWebkit1(const String& propertyName, const String& value, const String& priority) = 0;
> 
> Not sure what to do about this. I couldn't get a document from the webkit 1 code. It is script wrappable, but everything is null if you try to do [frameElement setProperty:...] from mini browser.

Any style declaration that actually participates in style resolution is connected to a document. You should be able to reach the associated document via either parentElement() or parentStyleSheet() (depending if it is an inline style declaration or part of a style rule on a stylesheet).

[Justin Michaud]

Created attachment 352407 [details]
Patch

[Justin Michaud]

Created attachment 352418 [details]
Patch

[Justin Michaud]

Created attachment 352422 [details]
Patch

[Justin Michaud]

Created attachment 352425 [details]
Patch

[EWS Watchlist]

Comment on attachment 352425 [details]
Patch

Attachment 352425 [details] did not pass mac-ews (mac):
Output: https://webkit-queues.webkit.org/results/9608740

New failing tests:
fast/css/variables/env/safe-area-inset-env-cannot-override.html
fast/css/variables/env/safe-area-inset-env-zero.html
fullscreen/fullscreen-env.html

[EWS Watchlist]

Created attachment 352432 [details]
Archive of layout-test-results from ews101 for mac-sierra

The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: ews101  Port: mac-sierra  Platform: Mac OS X 10.12.6

[Justin Michaud]

Created attachment 352433 [details]
Patch

[Justin Michaud]

Created attachment 352436 [details]
Style refactor (most contentious subset of full patch)

This is a subset of the full patch that contains the bulk of the refactoring. Hopefully, this should be easier to review. Once this part looks good, then the rest of the review should be fairly straightforward.

[Antti Koivisto]

Comment on attachment 352433 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=352433&action=review

> Source/WebCore/css/CSSStyleDeclaration.h:61
> -    virtual ExceptionOr<void> setProperty(const String& propertyName, const String& value, const String& priority) = 0;
> +    virtual ExceptionOr<void> setProperty(const Document&, const String& propertyName, const String& value, const String& priority) = 0;

This and all the related changes seem unnecessary. Document is available to concrete implementations of CSSStyleDeclaration when they are in-document.

[Antti Koivisto]

> Style refactor (most contentious subset of full patch)

What is contentious about it? 

In general it would be good to find subsets that can be landed separately. A non-compiling subset patch is not helpful.

[Justin Michaud]

Created attachment 352473 [details]
Patch

[EWS Watchlist]

Comment on attachment 352473 [details]
Patch

Attachment 352473 [details] did not pass mac-ews (mac):
Output: https://webkit-queues.webkit.org/results/9624274

New failing tests:
fast/css/getMatchedCSSProperties-rule-mutation.html

[EWS Watchlist]

Created attachment 352482 [details]
Archive of layout-test-results from ews100 for mac-sierra

The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: ews100  Port: mac-sierra  Platform: Mac OS X 10.12.6

[EWS Watchlist]

Comment on attachment 352473 [details]
Patch

Attachment 352473 [details] did not pass mac-wk2-ews (mac-wk2):
Output: https://webkit-queues.webkit.org/results/9625328

New failing tests:
fast/css/getMatchedCSSProperties-rule-mutation.html

[EWS Watchlist]

Created attachment 352490 [details]
Archive of layout-test-results from ews106 for mac-sierra-wk2

The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: ews106  Port: mac-sierra-wk2  Platform: Mac OS X 10.12.6

[EWS Watchlist]

Comment on attachment 352473 [details]
Patch

Attachment 352473 [details] did not pass win-ews (win):
Output: https://webkit-queues.webkit.org/results/9625420

New failing tests:
fast/css/getMatchedCSSProperties-rule-mutation.html

[EWS Watchlist]

Created attachment 352492 [details]
Archive of layout-test-results from ews206 for win-future

The attached test failures were seen while running run-webkit-tests on the win-ews.
Bot: ews206  Port: win-future  Platform: CYGWIN_NT-6.1-2.9.0-0.318-5-3-x86_64-64bit

[Justin Michaud]

Created attachment 352496 [details]
Patch

[Justin Michaud]

Created attachment 352508 [details]
Patch

[Justin Michaud]

(In reply to Antti Koivisto from comment #17)
> > Style refactor (most contentious subset of full patch)
> 
> What is contentious about it? 
> 
> In general it would be good to find subsets that can be landed separately. A
> non-compiling subset patch is not helpful.

I figured the changes to applyCascadedProperty would be the riskiest, and also the most likely to introduce performance regressions. I am not really sure how to split this up into parts that can land separately, since most of the changes that are not related to the refactor fix regressions caused by it. If you see anything, please let me know.

I removed the document changes, and that helped to bring down the size of the patch. Thanks for the tip. The reason it wasn't working before was because it caused setProperty to crash when used on a style from DOMWindow::getMatchedCSSRules. Moving the willMutate() check up fixed that though.

[Dean Jackson]

Comment on attachment 352508 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=352508&action=review

> Source/WebCore/css/CSSVariableReferenceValue.cpp:68
> +    // Apply this variable first, in case it is still unresolved

Nit: End with .

> Source/WebCore/css/CSSVariableReferenceValue.cpp:71
> +    // Apply fallback to detect cycles

Ditto.

> Source/WebCore/css/CSSVariableReferenceValue.cpp:100
> +    bool success = true;
> +    while (!range.atEnd()) {
> +        if (range.peek().functionId() == CSSValueVar || range.peek().functionId() == CSSValueEnv)
> +            success &= resolveVariableReference(range.consumeBlock(), result, state);
> +        else
> +            result.append(range.consume());
> +    }
> +    return success;

If the resolve fails, could you just return false instantly?

> Source/WebCore/css/DOMCSSRegisterCustomProperty.cpp:49
> +        // We don't actually need the values to be accurate, since they will be rejected later anyway

Nit: .

[Justin Michaud]

(In reply to Dean Jackson from comment #28)
> > Source/WebCore/css/CSSVariableReferenceValue.cpp:100
> > +    bool success = true;
> > +    while (!range.atEnd()) {
> > +        if (range.peek().functionId() == CSSValueVar || range.peek().functionId() == CSSValueEnv)
> > +            success &= resolveVariableReference(range.consumeBlock(), result, state);
> > +        else
> > +            result.append(range.consume());
> > +    }
> > +    return success;
> 
> If the resolve fails, could you just return false instantly?

I don't think so. The original code probably could, but now if I would return early, it could miss some cycles. The spec says that any cycles should cause all custom properties in the cycle to be reset, even if we would have been able to resolve the value.

[Antti Koivisto]

Comment on attachment 352508 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=352508&action=review

Looks good, r=me with the issue in PropertySetCSSStyleDeclaration::setProperty fixed. 

It would also be nice to add a test case for that.

> Source/WebCore/css/CSSCustomPropertyValue.cpp:45
> +    auto visitor = WTF::makeVisitor([&](const Ref<CSSVariableReferenceValue>& value) {
> +        return value.get() == WTF::get<Ref<CSSVariableReferenceValue>>(other.m_value).get();
> +    }, [&](const CSSValueID& value) {
> +        return value == WTF::get<CSSValueID>(other.m_value);
> +    }, [&](const Ref<CSSVariableData>& value) {
> +        return value.get() == WTF::get<Ref<CSSVariableData>>(other.m_value).get();
> +    }, [&](const Length& value) {
> +        return value == WTF::get<Length>(other.m_value);
> +    });
> +    return WTF::visit(visitor, m_value);

Variant has operator==. Why can't you use that?

> Source/WebCore/css/CSSCustomPropertyValue.h:44
> +using CSSCustomPropertyValueVariant = Variant<Ref<CSSVariableReferenceValue>, CSSValueID, Ref<CSSVariableData>, Length>;
> +
>  class CSSCustomPropertyValue final : public CSSValue {

You might consider scoping the Variant type into the CSSCustomPropertyValue namespace? CSSCustomPropertyValue::VariantValue or something.

> Source/WebCore/css/CSSStyleSheet.h:84
> -    Document* ownerDocument() const;
> +    WEBCORE_EXPORT Document* ownerDocument() const;

Does this really need to be exported?

> Source/WebCore/css/DOMCSSRegisterCustomProperty.cpp:70
> +    document.styleScope().didChangeStyleSheetEnvironment();

This triggers full re-evaluation of stylesheets.  Is this something that is expected to be rare in practice? Are there ways to optimize this in the future?

> Source/WebCore/css/PropertySetCSSStyleDeclaration.cpp:233
> +    ASSERT(parentElement() || parentStyleSheet());

This is not correct. You can have completely detached CSSStyleDeclaration, for example:

let styleDecl = element.style;
element.removeAttribute("style");
// styleDecl is now detached

(didn't try, just by reading code)

Maybe willMutate() should return false in this case, but it currently doesn't.

> Source/WebCore/css/PropertySetCSSStyleDeclaration.cpp:241
> +    ASSERT(document);

As a result document may be null too.

> Source/WebCore/css/StyleResolver.cpp:432
> +    ApplyCascadedPropertyState applyState { this, &cascade, &result, { }, { }, { }, { } };

Please get rid of { }, { }, { }, { } repeated everywhere. I think you can just remove them, but if not, just add a constructor.

> Source/WebCore/css/StyleResolver.cpp:2342
> +        if (state.inProgress.contains(propertyID)) {

'inProgressProperties' and 'inProgressCustomProperties' would be more consistent and informative names.

> Source/WebCore/css/StyleResolver.h:539
> +// State to use when applying properties, to keep track of which custom and high-priority
> +// properties have been resolved.
> +struct ApplyCascadedPropertyState {
> +    StyleResolver* styleResolver;
> +    StyleResolver::CascadedProperties* cascade;
> +    const StyleResolver::MatchResult* matchResult;
> +    HashSet<CSSPropertyID> appliedProperties;
> +    HashSet<String> appliedCustomProperties;
> +    HashSet<CSSPropertyID> inProgress;
> +    HashSet<String> inProgressCustom;
> +};

We should split out some of this stuff from StyleResolver at some point.

> Source/WebCore/css/parser/CSSParser.cpp:234
> +    auto visitor = WTF::makeVisitor([&](const Ref<CSSVariableReferenceValue>& value) {
> +        valueWithReferences = value.ptr();
> +    }, [&](const CSSValueID&) {
> +        ASSERT_NOT_REACHED();
> +    }, [&](const Ref<CSSVariableData>&) {
> +        ASSERT_NOT_REACHED();
> +    }, [&](const Length&) {
> +        ASSERT_NOT_REACHED();
> +    });
> +    WTF::visit(visitor, customPropValue.value());

Please just use WTF::get<> instead of a visitor.

> Source/WebCore/css/parser/CSSPropertyParser.h:54
> +    CSSPropertyParser(const CSSParserTokenRange&, const CSSParserContext&, Vector<CSSProperty, 256>*, bool consumeWhitespace = true);

Please use enum class for consumeWhitespace, booleans in call sites are confusing.

[Justin Michaud]

Comment on attachment 352508 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=352508&action=review

>> Source/WebCore/css/CSSCustomPropertyValue.cpp:45
>> +    return WTF::visit(visitor, m_value);
> 
> Variant has operator==. Why can't you use that?

Ref<> doesn't seem to have operator==, or at least if it does, I couldn't get it to work. Should I just add it?

>> Source/WebCore/css/DOMCSSRegisterCustomProperty.cpp:70
>> +    document.styleScope().didChangeStyleSheetEnvironment();
> 
> This triggers full re-evaluation of stylesheets.  Is this something that is expected to be rare in practice? Are there ways to optimize this in the future?

I am not sure how common this will be in practice. That depends on the number of registered custom properties that web authors use. I suppose we could only invalidate styles that contain a reference to this variable in the future.

[Justin Michaud]

Comment on attachment 352508 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=352508&action=review

>> Source/WebCore/css/PropertySetCSSStyleDeclaration.cpp:233
>> +    ASSERT(parentElement() || parentStyleSheet());
> 
> This is not correct. You can have completely detached CSSStyleDeclaration, for example:
> 
> let styleDecl = element.style;
> element.removeAttribute("style");
> // styleDecl is now detached
> 
> (didn't try, just by reading code)
> 
> Maybe willMutate() should return false in this case, but it currently doesn't.

I removed the assertion, and treat the case without a document as if there are no registered properties. I tried to write a test for it, but removeAttribute doesn't actually unset the parentElement (same on Chrome). I can't think of any way to trigger this case, please let me know if you have any ideas.

[Justin Michaud]

Created attachment 352848 [details]
Patch

[Antti Koivisto]

> Ref<> doesn't seem to have operator==, or at least if it does, I couldn't
> get it to work. Should I just add it?

It doesn't need to be done for this patch. Maybe the reason it hasn't been added is the question whether it should be a deep comparison or a pointer comparison (it probably should be deep, for consistency with &).

[Antti Koivisto]

(In reply to Justin Michaud from comment #32)
> Comment on attachment 352508 [details]
> Patch
> I removed the assertion, and treat the case without a document as if there
> are no registered properties. I tried to write a test for it, but
> removeAttribute doesn't actually unset the parentElement (same on Chrome). I
> can't think of any way to trigger this case, please let me know if you have
> any ideas.

StyledElement::styleAttributeChanged has a path that calls clearParentElement so this appears to be possible

[Antti Koivisto]

Comment on attachment 352848 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=352848&action=review

> Source/WebCore/css/StyleProperties.cpp:794
> +    auto* registered = document? document->getCSSRegisteredCustomPropertySet().get(propertyName) : nullptr;

Space before '?'

> Source/WebCore/css/StyleResolver.h:545
> +    HashSet<CSSPropertyID> appliedProperties;
> +    HashSet<String> appliedCustomProperties;
> +    HashSet<CSSPropertyID> inProgressProperties;
> +    HashSet<String> inProgressPropertiesCustom;
> +
> +    ApplyCascadedPropertyState(StyleResolver* styleResolver, StyleResolver::CascadedProperties* cascade, const StyleResolver::MatchResult* matchResult)
> +        : styleResolver(styleResolver)
> +        , cascade(cascade)
> +        , matchResult(matchResult)
> +    {
> +    }

Wonder if just having

HashSet<CSSPropertyID> appliedProperties = { }; 
...

would work instead of constructor? This stuff has been changing in C++11/14/17

> Source/WebCore/css/parser/CSSParser.cpp:222
> +    const CSSCustomPropertyValue& customPropValue = downcast<CSSCustomPropertyValue>(value);

could just use auto to avoid repeating CSSCustomPropertyValue

> Source/WebCore/css/parser/CSSParser.cpp:223
> +    const auto& valueWithReferences = WTF::get<Ref<CSSVariableReferenceValue>>(customPropValue.value()).get();

Should there be an assert before get? Not sure if get asserts itself.

[Justin Michaud]

Created attachment 352916 [details]
Patch

[Justin Michaud]

(In reply to Antti Koivisto from comment #36)

> Should there be an assert before get? Not sure if get asserts itself.

I checked. It seems like it does assert that the type index is correct.

[WebKit Commit Bot]

Comment on attachment 352916 [details]
Patch

Clearing flags on attachment: 352916

Committed r237347: <https://trac.webkit.org/changeset/237347>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[Radar WebKit Bug Importer]

<rdar://problem/45477680>