[Webkit-unassigned] [Bug 119356] [Forms: color] <input type='color'> popover color well implementation

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=119356





--- Comment #7 from Ruth Fong <ruthiecftg at gmail.com>  2013-08-01 00:16:27 PST ---
(From update of attachment 207899)
View in context: https://bugs.webkit.org/attachment.cgi?id=207899&action=review

> Source/WebKit2/UIProcess/WebPageProxy.cpp:2944
> +#if ENABLE(INPUT_TYPE_COLOR_POPOVER)
> +    m_colorPicker = m_pageClient->createColorPicker(this, initialColor, elementRect);
> +#else
>      if (!m_colorPicker)
>          m_colorPicker = m_pageClient->createColorPicker(this, initialColor, elementRect);
>      m_colorPicker->showColorPicker(initialColor);
> +#endif

Every time a new <input type='color'> element is activated, the previous popover is destroyed and a new one constructed. This differs from the panel implementation; which "resets" the color picker instead of tearing it down and building a new one when it's associated to another color element. Should we standardize the implementation? (Probably yes, that where there's a more similar implementation for the color picker UIs in WebColorPickerMac.)

Disadvantage of createIfNeeded-and-show: It'd be harder to follow the createIfNeeded then show model for popover because in WKColorPopoverMac, initForFrame needs to be called to set the popover over the right color element, but it can be done (more information would have to be passed to showColorPicker, such as elementRect and m_pageClient->wkView()).

For destroy-and-create: For the panel implementation, it may be a poor UI experience (will try it out) having a picker disappear and then reappear.

> Source/WebKit2/UIProcess/mac/WebColorPickerMac.mm:103
> +#endif

The deconstructor probably shouldn't have the ASSERT. Will file a new bug to fix this.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.