Created attachment 445036 [details] Basid range input logging input and change events <input type=range> does not fire the 'input' event when using the OS accessibility action APIs to increment/decrement it's value. Both macOS and iOS VoiceOver use the increment/decrement actions. This can break code that relies on only the 'input' event to respond to the range input changing values. 1. Open either the attached chromebug-1272108.html or https://westonthayer.github.io/hosting/chromebug-1272107.html in Safari 2. Open Xcode Accessibility Inspector 3. Select the range input (you can use Accessibility Inspector's Point to Inspect crosshairs) 4. Accessibility Inspector's inspected element should have type: slider 5. Expand Accessibility Inspector's Actions menu and perform either the 'increment' or 'decrement' actions Expected result: The log below the range input should show both "input: NEW_VALUE" and "change: NEW_VALUE", just as it does if you use the mouse or keyboard to change the range input's value. Actual result: The log only shows "change: NEW_VALUE".
<rdar://problem/85707481>
I believe firing 'input' is required by the HTML spec: https://html.spec.whatwg.org/multipage/indices.html#event-input
This is still a problem on macOS 14.3 with Safari 17.3 and on iOS 17.3.1. In practice, it's less of an issue with macOS as users likely change the value with up, down, left, right arrows without a modifier, triggering both events as any keyboard user would. The problem can still be replicated by navigating "In slider" (VO+Shift+down arrow) then using VO+up, down, left, right arrows; 'change' events are triggered but 'input' events are not.
Created attachment 470797 [details] Patch
Created attachment 470801 [details] Patch
Committed 277182@main (87dc85177fd8): <https://commits.webkit.org/277182@main> All reviewed patches have been landed. Closing bug and clearing flags on attachment 470801 [details].