select/ngOptions fails to update model after keyboard selection

[43081j]

See here:
http://plnkr.co/edit/9VymegmYt3tZPTH65Gj8?p=preview

Follow these steps:

• Enter the first input
• Tab to select
• Press a
• Press down

See that foo is now incorrect. If you use the mouse to select another and then reselect the same one, it then updates correctly.

Seems a rather odd, specific issue so im not entirely sure where in the chain this is occurring.

[leonardosalles]

+1

[caitp]

OTOH, it's because we aren't getting a change event. If we are in fact getting a change event then this is weird and warrants more investigation (this issue has been reported before however, I suggest reviewing old issues to find them).

[btford]

What browser are you seeing this in? I can't seem to reproduce in Chrome

[leonardosalles]

I'm using Chrome 37.0.2062.120 m in windows and I can reproduce the same bug, Chrome is in the latest version have no updates available

[caitp]

you could try in chrome 39 --- but yes, this sort of thing would be a browser bug (if we aren't getting the event we expect)

[43081j]

I attached an event listener to the <select> directly to console.log(this.value) and it never logged for the missing one.

So it would appear you are correct @caitp, it seems it could be a browser bug after all.

Although, I can't seem to recreate it without angular...

[43081j]

hmm it may be in angular actually.

if i remove the default change listener angular adds, so it only has my custom listener logging this.value, it works fine and is fired for both changes.

[gkalpak]

I don't know if we can call this a bug, but it's certainly inconsistent.

Some obesrvations:

1. In Firefox the change event isn't fired until the element loses focus (when you change the value using the keyboard). This is probably consistent with spec (but not very useful for us :().
2. In Chrome everythng works "as expected" (or "as we'd want it to") when there is a default empty option: <option value="">--</option>
3. In Chrome, the issue appears only under the following circumstances:
   a. Initialy there is nothing selected.
   b. Some value is selected (either by mouse or by keyboard).
   c. (Without losing focus) we change the selected value by keyboard (eithertyping a letter or using the down or right arrow). Surprisingly enough using the up/left arrow does fire the change event.
   d. After the above steps any interaction with the element that changes the selected value (either by mouse or by keyboard) fires the change event.

---

This answer on StackOverflow has some interesting info:

It seems that according to the spec "the onchange event occurs when a control loses the input focus and its value has been modified since gaining focus."

From what I read and what I understand, most vendor do not follow the "fire on blur" rule, but instead fire the event when the element's value has been committed by the user. The problem is that each vendor seems to have their own interpretation about when a value has been commited.
Chrome for example seems to consider each keypress to be committing the value (except for the inconsistency described above which is probably a bug or some weird corner-case).
(UPDATE: Based on 43081j's comment, this inconsistency might be Angular's fault.)
Firefox on the other hand, probably does not consider hitting the down arrow as committing the value (since theoretically, this could be the first in a series of clicks aiming to selected the nth value).

Anyway, the point is that I don't expect we can get any consistent behaviour if we rely on the change event, so Angular might need to hook into some other event as well (keypress, input ?).

[caitp]

Consistent behaviour doesn't really matter here (insofar as ensuring that we consistently update the model at the same time), because we don't need to change the model before a user commits to a value --- however the problem is that we aren't changing the value at all in these cases, which indicates that the change event isn't being dispatched at all. That is a much bigger problem

(https://html.spec.whatwg.org/multipage/forms.html#event-input-change for reference)

[43081j]

After some further investigation of this, the issue only occurs when the angular event loop occurs.

It seems that after the first change, the listener is somehow disabled (as no events fire on it). Then when you cause another change, it is back.

I commented out the code which iterates over event callbacks. So the angular callback is entered but doesn't fire the function the select directive defines. It then works fine, fires events as expected.

So whatever the callback select adds does, somehow causes the next set of events to not fire.

[43081j]

It would be worth testing without ngOptions. I think it is specific to that, maybe related to the code which recomputes the options each time validate and parse runs. As that probably alters the DOM?