<select> onChange not firing when using keyboard

[iotch]

Hello. On Firefox (v31 and 40 at least) when changing <select> values from keyboard onChange not firing, actually it fires only on blur: https://jsfiddle.net/mh3mn8st/
React 15.1.0.
thanks!

[aweary]

By on blur do you mean after you've selected an item and the menu goes away? I believe that is when the change event is actually fired. Until a selection is made, a change hasn't occurred. You can see the native behavior here: https://jsfiddle.net/L3yapeu9/ demonstrating that the event doesn't occur until a selection is made.

[iotch]

I mean when menu is closed, but changing selection with keyboard up/down keys. In Chrome, Opera, IE event is fired immediately, but in FF it fires when loses focus. So it seems like it's impossible to have a consistent behavior across all browsers?

[aweary]

@iotch I can't reproduce that behavior, both the React and native example fire the change event after a selection is made, not after the input is blurred. This is consistent in Firefox and Chrome on my machine (OS X)

Are you seeing the same behavior in the native example JSFiddle I posted?

[iotch]

Yes, I'm seeing the difference described in Firefox on Windows 8 and 8.1.

[jimfb]

Yeah, I'm seeing the same (presumably buggy) behavior.

I know Firefox does (or did?) have a notion of "confirmation" - namely that the value didn't take effect until the user locks in a choice, but I don't think that's what's going on here. Specifically, if I change the value with the keyboard, I see the node.value change (http://jsfiddle.net/8oee3ur2/) but as per the user's fiddle, it appears to not fire a change event despite the fact that node.value has changed.

cc @jquense @syranide @zpao

[jquense]

It doesn't look like FF is firing onInput events there, Change is only fired when you select or blur (doesn't work with the select closed and focused either)

[jimfb]

So presumably we want to listen to keyboard events and polyfill?

[jquense]

I'm not sure, I'd be interested in why FF made that choice. Not sure where the line is between allowing browsers to make different calls on non-speced stuff. Presumably because node.value is changing it should also be firing an onInput, but that may be a bug the other way just as easily...

[aweary]

Seems like this is a longstanding issue in Firefox https://bugzilla.mozilla.org/show_bug.cgi?id=126379

[aweary]

Is there currently a semantic way to polyfill this behavior only for a specific browser? I'm not familiar with the React event system, but it seems like we'd want to avoid listening/responding to keyboard events in browsers that are actually firing the input/change events.

[jquense]

I feel fine just calling this "A choice about widget interaction" vs a bug. Unless it's specced its just a reasonable to see keyboard up/down as analogous to scanning the list with the mouse.

If we did want to "fix" it though with the value dedupe logic it may be a simple matter of just listening and checking the value. This may create a lot of noise in safari which doesn't dedupe change events (because UGH Safari)

[aweary]

Well, it is considered a bug per the bugzilla report. It was initially a wontfix but they reopened it and its current status is unresolved. Does the HTML5 spec clarify this behavior at all? In the bugzilla report their initial justification for this behavior is from the HTML4 spec:

The onchange event occurs when a control loses the input focus and its value has been modified since gaining focus.

I couldn't find any clarification on that behavior in the HTML5 spec though. But since it's already considered a bug and React already does normalizations it doesn't seem unreasonable to normalize the behavior here.

[jquense]

it doesn't seem unreasonable to normalize the behavior here.

I agree, though the cost of those normalizations is not zero, so worth talking about in these gray areas.

Does the HTML5 spec clarify this behavior at all?

My general understanding is that once "inside" a widget its up to the implementor, consider the date input which only fires changes when all date sections are filled in. That example is intuitive i agree, but illustrates the fuzziness. in FF case, they are considering keydowns to be item scanning vs selection.

To the argument for polyfilling it, is this a11y concern (which seems minor) https://bugzilla.mozilla.org/show_bug.cgi?id=126379#c171

[aweary]

Yeah if the cost of polyfilling this is relatively low I'd say it'd be worth a shot. But I'm honestly not sure yet what it would take, I'm interested in figuring that out. The behavior was implemented based on an oudated spec and was just never changed, so making it consistent and a11y friendly would be nice.