| Summary: | Inconsistent 'change' event dispatch on color input | ||||||
|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Dan <dan> | ||||
| Component: | Forms | Assignee: | 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: |
|
||||||
Related Google Chrome issue, marked as fixed: https://bugs.chromium.org/p/chromium/issues/detail?id=405059 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. |
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.