[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