Summary: | Registered custom properties should support syntax parameter for <length> and * | ||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Justin Michaud <justin_michaud> | ||||||||||||||||||||||||||||||||||||||
Component: | Layout and Rendering | Assignee: | Justin Michaud <justin_michaud> | ||||||||||||||||||||||||||||||||||||||
Status: | RESOLVED FIXED | ||||||||||||||||||||||||||||||||||||||||
Severity: | Normal | CC: | bfulgham, commit-queue, dino, don.olmstead, ews-watchlist, koivisto, rniwa, simon.fraser, webkit-bug-importer, zalan | ||||||||||||||||||||||||||||||||||||||
Priority: | P2 | Keywords: | InRadar | ||||||||||||||||||||||||||||||||||||||
Version: | WebKit Nightly Build | ||||||||||||||||||||||||||||||||||||||||
Hardware: | Unspecified | ||||||||||||||||||||||||||||||||||||||||
OS: | Unspecified | ||||||||||||||||||||||||||||||||||||||||
Bug Depends on: | |||||||||||||||||||||||||||||||||||||||||
Bug Blocks: | 184542, 189692 | ||||||||||||||||||||||||||||||||||||||||
Attachments: |
|
Description
Justin Michaud
2018-09-27 08:42:36 PDT
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
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.
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 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
Created attachment 352251 [details]
Patch
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 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). Created attachment 352407 [details]
Patch
Created attachment 352418 [details]
Patch
Created attachment 352422 [details]
Patch
Created attachment 352425 [details]
Patch
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 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
Created attachment 352433 [details]
Patch
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.
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. > 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.
Created attachment 352473 [details]
Patch
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 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
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 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
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 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
Created attachment 352496 [details]
Patch
Created attachment 352508 [details]
Patch
(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. 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: . (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. 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. 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. 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. Created attachment 352848 [details]
Patch
> 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 &).
(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 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. Created attachment 352916 [details]
Patch
(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. Comment on attachment 352916 [details] Patch Clearing flags on attachment: 352916 Committed r237347: <https://trac.webkit.org/changeset/237347> All reviewed patches have been landed. Closing bug. |