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?

[43081j]

See the following:
http://plnkr.co/edit/EWm2czsxySUeozotE99p?p=preview

Removed ngOptions to help narrow the problem down.

It appears that angular adds an option <option value="? object:null ?"></option> which is removed on first change, using jqLiteRemove. That then causes the events to not fire until the next change (or focus), for reasons I can't seem to figure out.

[gkalpak]

@43081j: The problem appears even without the <option value="?..." element.
For example it also happens when there is no default empty option and you use ngOptions which creates an <option value=""></option>.

This might have something to do with Angular trying to reuse existing <option> elements for efficiency (but I haven't fully tracked the problem down).

[43081j]

Yup I see. It is definitely related to angular removing/changing <option> elements I think.

If I force it to not remove that option, it works fine. If I skip the code which reuses <option> elements, with ngOptions, it also works fine. So I guess altering the child nodes is somehow breaking the events.

[43081j]

It is a browser bug.

http://plnkr.co/edit/hJx7nOFavOg98btF0ixN?p=preview

It occurs when you remove (or maybe change) an <option> at an index below the one you are selecting. Removing one after the selected does not cause this issue, only before.

Leads me to believe its some bug with chrome keeping track of options, indexes changing etc.

[gkalpak]

@43081j, I believe this is how you meant the plunkr to work: http://plnkr.co/edit/4dOxvFpQZMwHl0nPVhHL?p=preview

Indeed, it seems to be a browser issue.
But, since we know what causes it (removing the automatically added empty option), would it make sense for Angular to find a way not to step onto that bug ? Or should we rely on Chrome to fix the bug ?
(@caitp, what is the usual course of action is such cases ?)

[43081j]

ah yes my mistake, I assigned the event return to the var instead of the actual callback.

I raised an issue on chrome's tracker for this also, FYI.

[gkalpak]

@43081j: It would be good to post the link here for reference.

[43081j]

Here you go:
https://code.google.com/p/chromium/issues/detail?id=415505

May be wrong to place it in their JS category, I'm not sure where it fits.

[Narretz]

It might make sense to track both issues separately: This here for Chrome not firing change when an option is removed (probably), see https://code.google.com/p/chromium/issues/detail?id=415505

And another one for Firefox because it is not firing change when the select value is changed via keyboard. There was one already, but it's closed now: #4216 @caitp, what's the policy on browser bugs (https://bugzilla.mozilla.org/show_bug.cgi?id=126379)? I think keep them open either until the vendor fixes them or we implement a workaround, right?

[clarker0]

+1, this issue is causing me problems so glad you've narrowed this down. It's definitely a bug in Blink/WebKit as it affects Opera as well, maybe we should file a bug report there too?

And IE fires the onchange event every time as expected. Firefox is the only one that actually follows the spec! 😒

[Narretz]

I just closed some duplicates of this issue, so here's a quick recap:

Chrome (Blink) / Safari (webkit) has a bug not firing change when an option is removed. Bug filed as https://code.google.com/p/chromium/issues/detail?id=415505 (Bug is fixed in Chrome)

Firefox basically follows the "spirit of the spec" by not firing change when the select value is changed via keyboard, but Chrome and IE do it, so it coud be considered a bug. Tracked as https://bugzilla.mozilla.org/show_bug.cgi?id=126379.

As a workaround, you can add a directive that fires the change event on keyup (thanks to @gkalpak for this):

directive('changeOnKeyup', function changeOnKeyupDirective() {
  return function changeOnKeyupPostLink(scope, elem) {
    elem.on('keyup', elem.triggerHandler.bind(elem, 'change'));
  };
});

Fixed plnkr

[doug65536]

@Narretz Isn't that a memory leak? You need a $destroy handler to remove the .on event handler.

[Narretz]

The Chrome has been fixed: https://code.google.com/p/chromium/issues/detail?id=415505

[Narretz]

Wrt the Firefox behavior, we have to accept that this is a browser quirk that must be fixed by Firefox, or worked around as specified. I have added a note in the select docs (dcc57f1) and will close this issue.