[webkit-reviews] review granted: [Bug 177489] [iOS] Respect the "caret-color" CSS property when editing : [Attachment 322878] Patch

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Thu Oct 5 12:06:22 PDT 2017


Tim Horton <thorton at apple.com> has granted Aishwarya Nirmal
<anirmal at apple.com>'s request for review:
Bug 177489: [iOS] Respect the "caret-color" CSS property when editing
https://bugs.webkit.org/show_bug.cgi?id=177489

Attachment 322878: Patch

https://bugs.webkit.org/attachment.cgi?id=322878&action=review




--- Comment #7 from Tim Horton <thorton at apple.com> ---
Comment on attachment 322878
  --> https://bugs.webkit.org/attachment.cgi?id=322878
Patch

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

> Source/WebKit/Shared/EditorState.h:105
> +	   WebCore::Color caretColor { WebCore::Color::Color() };

You don't need the braces or anything inside, the default constructor will be
invoked regardless.

> Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm:2031
> +	       return [[[UIColor alloc]
initWithCGColor:cachedCGColor(caretColor)] autorelease];

UIColor has colorWithCGColor if you want to avoid the autorelease.

> Tools/TestWebKitAPI/Tests/WebKitCocoa/EditorStateTests.mm:314
> +    [redColor getRed:&redColorRed green:&redColorGreen blue:&redColorBlue
alpha:&redColorAlpha];

I wonder, can we not just use UIColor equality instead? Like
EXPECT_TRUE([insertionPointColor isEqual:redColor]);?

You're already going to fail if they're the same color in different color
spaces, which is the usual gotcha with isEqual, so that's not a reason not to.

Thoughts?


More information about the webkit-reviews mailing list