type=range does not fire onchange in response to keypresses

REOPENED
Unassigned

Status

()

Firefox
General
REOPENED
5 years ago
5 years ago

People

(Reporter: Stephan Sokolow, Unassigned)

Tracking

({access})

22 Branch
x86_64
Linux
access
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

5 years ago
I noticed a small problem when testing the new type=range support in Aurora 22.0a2 on http://html5tutorial.info/html5-range.php

When you change a slider's value using the keyboard, type=range defers onchange events until you give focus to another element.

This makes sense for select boxes, but it's unhelpful and counter-intuitive for sliders where retrieving updates to the value prior to the form being submitted is primarily used to provide a live preview of the value. (In the page I reference, it's used to update a textbox displaying the numerical value of the slider's current position. In other contexts, it could be used to redraw a canvas ruler or equivalent.)

I can't see any reasonable use for the current implementation (we already have onblur for what it's currently doing to keyboard users) and, when developers end up polling for updates, it'll just make the browser slower.

It also makes it much more awkward for advanced users to fine-tune the value of the slider. (In native applications, I quite often drag the slider to an approximate match, then use the keyboard to adjust by step increments. In the browser, even if this is fixed, that's my ONLY option since, in a perfectly reasonable move, onchange doesn't repeatedly fire as you drag the slider.)
Status: UNCONFIRMED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 853670

Comment 2

5 years ago
Not a dup.  This parallels the debate in bug 126379, by the way.
Keywords: access

Comment 3

5 years ago
In some ways, this is worse than bug 126379 for <select size=1>.  With <input type=range> web developers testing with mice have a clear incentive to use onchange rather than oninput, and end up making sites that don't work well for keyboard users.
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: DUPLICATE → ---
You need to log in before you can comment on or make changes to this bug.