Bug 227700 - Inconsistent 'change' event dispatch on color input
Summary: Inconsistent 'change' event dispatch on color input
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: Forms (show other bugs)
Version: Safari 14
Hardware: Unspecified macOS 11
: P2 Normal
Assignee: Nobody
Keywords: InRadar
Depends on:
Reported: 2021-07-06 03:39 PDT by Dan Burzo
Modified: 2021-07-07 11:49 PDT (History)
4 users (show)

See Also:

'input' and 'change' events on <input type=color> (456 bytes, text/html)
2021-07-06 03:39 PDT, Dan Burzo
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Dan Burzo 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.
Comment 1 Dan Burzo 2021-07-06 03:56:03 PDT
Related Google Chrome issue, marked as fixed: https://bugs.chromium.org/p/chromium/issues/detail?id=405059
Comment 2 Sam Sneddon [:gsnedders] 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.
Comment 3 Radar WebKit Bug Importer 2021-07-06 07:05:42 PDT