Version 1.2.15 broke functionality with select and ng-options

[dnchristiansen]

We have some functionality where it's possible that after a select is changed, the model could end up back at the same value it was before. This worked fine up to version 1.2.14. See this fiddle: http://jsfiddle.net/k8EaA/
As the select is changed, the select shows the correct model ('c') after it is changed.

See this fiddle with version 1.2.15: http://jsfiddle.net/kdG38/
As the select is changed, it stays on what it was changed to, and doesn't reflect what's in the model.

We also have some functionality that removes certain options in certain cases. Basically, we have a few selects that all have the same options, and then don't allow the same option to be selected for the other selects. We do this by removing options that are already selected in the other selects.
This issue only seems to be a problem in IE11. In IE11, view this fiddle with version 1.2.14: http://jsfiddle.net/uLUXP/
Change the last select to AAA. All the other selects show the correct value based on the model.

See this fiddle with version 1.2.15: http://jsfiddle.net/S37Yp/
Change the last select to AAA. All the other selects now show the first option, which does not match the model.

It seems very likely that this behavior was introduced with this commit: dc149de
I tried reverting those changes locally, and then the selects work as expected.

I tried all this with the latest 1.2.18 version, and these issues still exist.

[andhernand]

I have also seen the same behavior. See this fiddle: http://jsfiddle.net/andhernand/hLNF2/10/

The effects are heightened in Chrome on Android.

[lgalfaso]

Hi,
Can you check is this still an issue with #7136 ?

[andhernand]

The above patch does not fix the problem. I am seeing the same behavior with the patch applied.

[dnchristiansen]

With that patch, I still have both the issues mentioned above.

[jeffbcross]

@dnchristiansen I'm having trouble understanding the real-world use case for your first issue, where you would want to always change the value back to a hard-coded value after the user has changed the input. Can you describe a situation where you would want to do this, and what you're expecting Angular to do differently?

[dnchristiansen]

That fiddle is simplified to show the problem. The real code has a bunch of logic to determine what the model value should be after the select is changed, and there are cases where it ends up back at the same value as it was before. As far as what Angular should do differently, the select should be reflecting what it is in the model. It may seem like an obscure case to set a select back to same value it was before, but the bottom line is that the model and select are getting out of sync.

[IgorMinar]

we need to revert the commit that introduced this regression, but we don't have a fix for the issue that the reverted commit tried to fix yet. I looked into that but it's a bit more involved so it will take a few days.

[caitp]

I think there is a pretty narrow set of cases which would run into problems if we revert that commit --- it's basically only if digests are happening frequently while selecting an option... And in those cases (like an $interval firing frequently) it might be simpler to just tell people not to do that, until it's fixed in Gecko. There isn't much else we can do about it since we can't force the browser to do the right thing.

(So in other words, should just revert)

[Narretz]

@dnchristiansen
There's a fix (cdc7db3) in master that also fixes both regressions you posted:

http://jsfiddle.net/k8EaA/1/
http://jsfiddle.net/S37Yp/1/

Can you confirm that your issues are fixed with that?

[dnchristiansen]

I tried my app with this commit and the 1st issue is resolved.

I am still having some issues in my app with the 2nd issue, but the fiddle is obviously working. As the 2nd issue only happens in IE11, the 1st issue is higher priority for us. I don't have a problem with this issue being closed, and then I'll see if I can create a fiddle that shows the problem we still have in IE11. If I'm able to do that, I'll just open a new issue.

Is it safe to assume this commit will make its way into the v1.2.x branch?

[caitp]

The commit which broke it has already been reverted in v1.2.x (I think it was actually a pair of commits, so hopefully both were reverted)

[dnchristiansen]

Are those v1.2.x commits in a released version? Or will they be included in the next 1.2.x version?

[caitp]

they'll be released on monday I believe

[dnchristiansen]

As I am using the 1.2.x versions of angular, I wanted to confirm this issue was fixed with the next released version. However, the fiddles above with the latest code have definitely fixed the issue, so I will close this issue for now.