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.)
Not a dup. This parallels the debate in bug 126379, by the way.
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.