Bug 141529 - input type="color" duplicated colour well
Summary: input type="color" duplicated colour well
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: Forms (show other bugs)
Version: 528+ (Nightly build)
Hardware: Mac (Intel) OS X 10.10
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-02-12 12:59 PST by Tom Grimwood-Taylor
Modified: 2021-07-06 03:05 PDT (History)
3 users (show)

See Also:


Attachments
A very simple HTML document used in the above description (109 bytes, text/html)
2015-02-12 12:59 PST, Tom Grimwood-Taylor
no flags Details
Example used by my second comment (303 bytes, text/html)
2015-02-15 09:46 PST, Tom Grimwood-Taylor
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Tom Grimwood-Taylor 2015-02-12 12:59:57 PST
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.
Comment 1 Alex Christensen 2015-02-12 13:03:31 PST
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);
Comment 2 Tom Grimwood-Taylor 2015-02-15 09:46:07 PST
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.
Comment 3 Tom Grimwood-Taylor 2015-02-15 09:46:45 PST
Created attachment 246621 [details]
Example used by my second comment
Comment 4 Dan Burzo 2021-07-06 03:05:13 PDT
Can't reproduce issue in Safari 14 nor Safari 15 TP.