Skip to content
This repository was archived by the owner on Apr 12, 2024. It is now read-only.

Issue with ngOptions and empty option inside ngIf (IE10). #9008

Closed
wawyed opened this issue Sep 10, 2014 · 5 comments
Closed

Issue with ngOptions and empty option inside ngIf (IE10). #9008

wawyed opened this issue Sep 10, 2014 · 5 comments
Labels
browser: IE10 component: forms frequency: low resolution: fixed severity: broken expected use
Milestone
1.4.x

Comments

@wawyed
Copy link

wawyed commented Sep 10, 2014

We've spotted this issue while testing IE10 and it seems to be the only affected browser (we test chrome, firefox, ie10 and ie11).

Scenario:

-JS:

var app = angular.module('app', []);

app.controller('forms', function($scope) {
  $scope.o = {};
  $scope.opts2 = [];

  $scope.changeOptions = function(value) {
    $scope.opts2 = $scope.options[value];
  };

  $scope.opts = [{
    id: 'a',
    value: 'a'
  }, {
    id: 'b',
    value: 'b'
  }];

  $scope.options = {
    a: [{id: 'a1', value: 'a1'}],
    b: [{id: 'b1', value: 'b1'}]
  };
});

-HTML:

      <body>
        <div ng-app="app">
          <br>
          <form class="form" name="form" ng-controller="forms" novalidate="">
            <div class="form-group col-sm-3">
              <select ng-model="o.s" class="form-control" ng-options="value.id as value.value for value in opts" ng-change="changeOptions(o.s)">
                <option value=""></option>  
              </select>
            </div>
            <div class="form-group col-sm-3">
              <p>s = {{o.s}}</p>
            </div>
            <div class="form-group col-sm-3" ng-if="'true'">
              <select ng-model="o.s2" class="form-control" ng-options="v.id as v.value for v in opts2">
              <option value=""></option>
              </select>
            </div>
            <div class="form-group col-sm-3">
              <select ng-model="o.s2" class="form-control" ng-options="v.id as v.value for v in opts2">
              <option value=""></option>
              </select>
            </div>
          </form>
        </div>
      </body>

How to reproduce:

Using only the keyboard, tab to the first select and select the second value using the down key, this will trigger a ng-change that will update the options for the second select. Tab to the second select and select the first item, the displayed label will correspond to the first set of options. You will see that the select that it's surrounded by ngIf is displaying incorrect values while the select that doesn't shows the correct value.

This issue only occurs if the length of the options array matches and you have a blank option.

Expected result:

The labels should always match the selected option in the current ngOptions array.

Possible causes:

We think it could be related to the fact that ngIf clones the content of the element that it's attached to and the fact that selectDirective reuses DOM nodes instead of creating new ones.

Plunker that reproduces the issue:

http://plnkr.co/edit/DeOOqY3J0XnD0Dzc9w62?p=preview
@jeffbcross jeffbcross added this to the 1.3.0 milestone Sep 10, 2014
@caitp
Copy link
Contributor

caitp commented Sep 15, 2014

This looks like an issue that @wesleycho has dealt with before, which is this weird behaviour where the browser does know the right list of options, but the label doesn't update.

I think he actually had a PR to fix one manifestation of this bug --- but yeah it seems to be a browser bug, where the label is not dirty'd when the set of options changes unless a click occurs or something.

I think this is fixable, but it may not be fixable without some performance cost

@wesleycho
Copy link
Contributor

Igor did merge #8825 of mine, which may have fixed the issue, although I haven't been able to test it.

@caitp
Copy link
Contributor

caitp commented Sep 15, 2014

mmm, unfortunately that fix does not correct this behaviour. Usually this means we need to do something really hackish to make sure that IE dirties the input. This has a perf cost because A) it's more work, and B) it can unintentionally cause reflows and other unwanted nastiness. I don't know if we really want to solve it that way though.

@petebacondarwin
Copy link
Contributor

I think this is the same issue as #2809. Moving to 1.4.x milestone to be looked into further.

@Narretz
Copy link
Contributor

Narretz commented Apr 9, 2016

Can't reproduce anymore in 1.5.3, see http://embed.plnkr.co/GhotAU7lZ6yBGLCtg5St/

@Narretz Narretz closed this as completed Apr 9, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
browser: IE10 component: forms frequency: low resolution: fixed severity: broken expected use
Projects
None yet
Milestone
1.4.x
Development

No branches or pull requests
6 participants
@petebacondarwin @jeffbcross @Narretz @wesleycho @caitp @wawyed