Bug 227700

Summary: Inconsistent 'change' event dispatch on color input
Product: WebKit Reporter: Dan <dan>
Component: FormsAssignee: Nobody <webkit-unassigned>
Status: NEW    
Severity: Normal CC: akeerthi, cdumez, webkit-bug-importer, wenson_hsieh
Priority: P2 Keywords: InRadar
Version: Safari 14   
Hardware: Unspecified   
OS: macOS 11   
Attachments:
Description Flags
'input' and 'change' events on <input type=color> none

Dan
Reported 2021-07-06 03:39:12 PDT
Created attachment 432916 [details] 'input' and 'change' events on <input type=color> <input type=color/> opens a popup containing color swatches. Clicking on any color swatch produces an `input` event, followed by a `change` event and (crucially) closes the popup. The _Show colors..._ button opens up the macOS native color picker. Dragging the cursor around the color wheel produces pairs of `input` and `change` events. I believe `change` event should be reserved to the user committing the value change by dismissing the color picker. This would be consistent with behaviors in both Chrome/macOS and Firefox/macOS. Attached for convenience is a simple test case with a color input that logs its `input` and `change` events in the browser console.
Attachments
'input' and 'change' events on <input type=color> (456 bytes, text/html)
2021-07-06 03:39 PDT, Dan 		no flags
Details
View All Add attachment proposed patch, testcase, etc.
Dan
Comment 1 2021-07-06 03:56:03 PDT
Related Google Chrome issue, marked as fixed: https://bugs.chromium.org/p/chromium/issues/detail?id=405059
Sam Sneddon [:gsnedders]
Comment 2 2021-07-06 07:05:29 PDT
Per https://html.spec.whatwg.org/multipage/input.html#common-input-element-events: > The change event fires when the value is committed, if that makes sense for the control, or else when the control loses focus.
Radar WebKit Bug Importer
Comment 3 2021-07-06 07:05:42 PDT
<rdar://problem/80208921>
Note You need to log in before you can comment on or make changes to this bug.