Bug 141529 – input type="color" duplicated colour well

• Component: Forms
• Status: RESOLVED CONFIGURATION CHANGED

[Tom Grimwood-Taylor]

Created attachment 246470 [details]
A very simple HTML document used in the above description

The colour well displayed by <input type="color" /> is duplicated when the popover is displayed and the page scrolled. The duplicated well remains even after closing the popover.

To see the issue open the attached HTML document.
Click the color well to show the popover.
Scroll the page.
Note that there are now two wells, one in the original position and one attached to the popover.
Close the popover by clicking elsewhere on the page.
Scroll the page and note that there are still two wells.

[Alex Christensen]

Here's a speculative fix.  Try it and see if it fixes it.

Index: WebKit2/UIProcess/WebPageProxy.cpp
===================================================================
--- WebKit2/UIProcess/WebPageProxy.cpp	(revision 179993)
+++ WebKit2/UIProcess/WebPageProxy.cpp	(working copy)
@@ -3622,7 +3622,10 @@
 #if ENABLE(INPUT_TYPE_COLOR_POPOVER)
     // A new popover color well needs to be created (and the previous one destroyed) for
     // each activation of a color element.
-    m_colorPicker = 0;
+    if (m_colorPicker) {
+        m_colorPicker->invalidate();
+        m_colorPicker = nullptr;
+    }
 #endif
     if (!m_colorPicker)
         m_colorPicker = m_pageClient.createColorPicker(this, initialColor, elementRect);

[Tom Grimwood-Taylor]

The speculative fix attached by Alex Christensen doesn't fix the issue.

It may be more clear what the issue is in the second attachment.

Firstly, if you click the input element in the centre of the page and scroll down you'll see that there are two colour wells. One of them, the original, will scroll with the page as expected. The other, which has the popover attached, will remain fixed where the original well was before scrolling. So it appears that rather than attaching a popover to the existing colour well, a new one is created at a fixed position. I'd expect the popover to be attached to the existing one and scroll with it as the popovers attached to an event in Calendar.app do.

Secondly, when the page is clicked elsewhere the popover disappears as expected, but the duplicate colour well remains. If the original colour well is clicked, then the duplicate colour well will be removed and a new one added, again fixed in the new position of the original colour well.

I'll try to figure out how to write a test case for this.

[Tom Grimwood-Taylor]

Created attachment 246621 [details]
Example used by my second comment

[Dan]

Can't reproduce issue in Safari 14 nor Safari 15 TP.

[Ahmad Saleem]

I am not able to reproduce this bug in Safari 16 using attached test cases and as soon as I scroll, it invalidates and remove "color" input from the input and does not show any lingering or overhanging input popover. It is matching with other browsers except Firefox Nightly 107, which has color field as window rather than popover.

Since it is not happening and also confirmed in Comment 04, I am marking this as "RESOLVED CONFIGURATION CHANGED". Thanks!