[webkit-reviews] review granted: [Bug 126296] Remove hardcoded composition background color; use RenderStyle::compositionFillColor() : [Attachment 222250] Patch
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Mon Jan 27 10:04:29 PST 2014
Darin Adler <darin at apple.com> has granted Sam Weinig <sam at webkit.org>'s request
for review:
Bug 126296: Remove hardcoded composition background color; use
RenderStyle::compositionFillColor()
https://bugs.webkit.org/show_bug.cgi?id=126296
Attachment 222250: Patch
https://bugs.webkit.org/attachment.cgi?id=222250&action=review
------- Additional Comments from Darin Adler <darin at apple.com>
View in context: https://bugs.webkit.org/attachment.cgi?id=222250&action=review
> Source/WebCore/css/CSSComputedStyleDeclaration.cpp:2640
> + case CSSPropertyWebkitCompositionFillColor: {
> + if (!style->compositionFillColor().isValid())
> + return
cssValuePool().createColorValue(m_node->document().renderView()->theme().compos
itionFillColor().rgb());
> + return
cssValuePool().createColorValue(style->compositionFillColor().rgb());
> + }
No need for these braces.
I can’t find any other code in this function that dereferences renderView(); do
we have a solid guarantee that it’s non-null?
Is there a good reason to use m_node->document() rather than
styledNode->document()?
> Source/WebCore/platform/graphics/Color.h:-156
> - static const RGBA32 tap = 0x4D1A1A1A;
Obviously didn’t belong here, but where is the tap color now?
> Source/WebCore/platform/graphics/Color.h:156
>
> private:
Looks like we are leaving an extra blank line behind here.
> Source/WebCore/rendering/style/RenderStyle.h:1446
> + void setCompositionFillColor(const Color &c) {
SET_VAR(rareInheritedData, compositionFillColor, c); }
Move the "&" next to Color, please.
More information about the webkit-reviews
mailing list