[webkit-reviews] review denied: [Bug 65897] Implement <input type=color> UI WebKit chromium part : [Attachment 113841] Patch

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Mon Nov 14 23:20:32 PST 2011


Darin Fisher (:fishd, Google) <fishd at chromium.org> has denied Keishi Hattori
<keishi at webkit.org>'s request for review:
Bug 65897: Implement <input type=color> UI WebKit chromium part
https://bugs.webkit.org/show_bug.cgi?id=65897

Attachment 113841: Patch
https://bugs.webkit.org/attachment.cgi?id=113841&action=review

------- Additional Comments from Darin Fisher (:fishd, Google)
<fishd at chromium.org>
View in context: https://bugs.webkit.org/attachment.cgi?id=113841&action=review


> Source/WebKit/chromium/public/WebColorChooserClient.h:51
> +    virtual void didCleanup() = 0;

nit: I think using a term like "Close" here might be a bit clearer.  It seems
like
there are two events that you can receive from the color chooser.  Either, the
color was changed or the dialog was closed.

> Source/WebKit/chromium/src/ChromeClientImpl.cpp:673
> +    client->colorChooser()->setClient(colorChooserClient);

It seems like it would be better to create a new WebColorChooser for use by
WebKit.
It may be the case that you only ever want to make one color chooser visible to
the
user at a time, but by allocating a separate WebColorChooser for each
openColorChooser
call, you simplify some of the state management.  For example, your checks for
"colorChooser == client->colorChooser()->client()->colorChooser()" go away. 
Instead,
when WebKit wants to close the WebColorChooser instance, it just deletes it. 
When
WebKit wants to change the color shown in its WebColorChooser instance, it just
calls
a method on it.

So, I'd go with:

  class WebViewClient {
    ...
    virtual WebColorChooser* createColorChooser(WebColor initialColor,
WebColorChooserClient*) { return 0; }
    ...
  };


More information about the webkit-reviews mailing list