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
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2021-07-06 03:39 PDT by Dan
Modified: 2021-07-07 11:49 PDT (History)
4 users (show)

See Also:

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 an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Dan 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 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 
<rdar://problem/80208921>