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

Select ng-options is dont reset with '<input type="reset"> ' #14892

Closed
fovotz opened this issue Jul 10, 2016 · 3 comments · Fixed by #14894
Closed

Select ng-options is dont reset with '<input type="reset"> ' #14892

fovotz opened this issue Jul 10, 2016 · 3 comments · Fixed by #14894

Comments

@fovotz
Copy link

fovotz commented Jul 10, 2016

Note: for support questions, please use one of these channels: https://github.com/angular/angular.js/blob/master/CONTRIBUTING.md#question. This repository's issues are reserved for feature requests and bug reports.

Do you want to request a feature or report a bug?
Bug

What is the current behavior?
When I have a select with ng-options with an array with objects, the behavior is weird when I reset the form by clicking in a <input type="reset" value="clear">

The problem occurs because when you select an option angular put a attribute selected="selected" on the option and never clears the attribute in the others options.

If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem via https://plnkr.co or similar (template: http://plnkr.co/edit/tpl:yBpEi4).

Chosse different options in the select and then press the reset button.

You can watch the error here: https://plnkr.co/edit/Epq5fVrS0I6p2csrntli?p=preview

select-dom

What is the expected behavior?
The standard reset form button works properly

What is the motivation / use case for changing the behavior?
The standard reset form button doesn't works properly when ng-options is used with a array with objects.

Which versions of Angular, and which browser / OS are affected by this issue? Did this work in previous versions of Angular? Please also test with the latest stable and snapshot (https://code.angularjs.org/snapshot/) versions.
1.5.5, 1.5.7

Other information (e.g. stacktraces, related issues, suggestions how to fix)
The partial solution of this issue is commenting the line of the angular.js 1.5.5

28012 // option.element.setAttribute('selected', 'selected');

@gkalpak
Copy link
Member

gkalpak commented Jul 11, 2016

Wow! This seems to have been broken since 1.4.0-beta.6 (diff) - possibly by 6a03ca2.
(I wonder how come nobody reported it until now 😕 )

@Narretz
Copy link
Contributor

Narretz commented Jul 11, 2016

Might be related to #14419

@Narretz
Copy link
Contributor

Narretz commented Jul 11, 2016

Strange that his happens only with track by, though.
Because when you have track by, we are watching the track by expression, and that means when you select an option in a select with track by, the select will react to the model value change and call again the $render function with adds the selected attribute. This does not happen without track by.

So when the user selects an option, neither the browser nor we add the selected attribute. It is only added when the the model changes (for single selects)

Also note that we are actually interested in what happens when we set the model to {}. The reset button is irrelevant to the issue.

Narretz added a commit to Narretz/angular.js that referenced this issue Jul 11, 2016
When the select model changes, we add the "selected" attribute to the selected option, so that
screen readers know which option is selected.

Previously, we failed to remove the attribute when the model changed to match a different option, or
the unknown / empty option.

When using "track by", the behavior would also show when a user selected an option, and then the
model was changed, because track by watches the tracked expression, and calls the $render function
on change.

This fix reads the current select value, finds the matching option and removes the "selected"
attribute.

Fixes angular#14892
Fixes angular#14419
Related angular#12731
@Narretz Narretz self-assigned this Jul 11, 2016
Narretz added a commit to Narretz/angular.js that referenced this issue Jul 22, 2016
When the select model changes, we add the "selected" attribute to the selected option, so that
screen readers know which option is selected.

Previously, we failed to remove the attribute when the model changed to match a different option, or
the unknown / empty option.

When using "track by", the behavior would also show when a user selected an option, and then the
model was changed, because track by watches the tracked expression, and calls the $render function
on change.

This fix reads the current select value, finds the matching option and removes the "selected"
attribute.

Fixes angular#14892
Fixes angular#14419
Related angular#12731
Narretz added a commit to Narretz/angular.js that referenced this issue Jul 23, 2016
When the select model changes, we add the "selected" attribute to the selected option, so that
screen readers know which option is selected.

Previously, we failed to remove the attribute from the selected / empty option when the model changed
to match a different option, or the unknown / empty option.

When using "track by", the behavior would also show when a user selected an option, and then the
model was changed, because track by watches the tracked expression, and calls the $render function
on change.

This fix reads the current select value, finds the matching option and removes the "selected"
attribute.

IE9 had to be special cased, as it will report option.hasAttribute('selected') === true even
if the option's property and attribute have been unset (even the dev tools show not selected attribute).

I've added a custom matcher that accounts for this behavior. In all other browsers, property and
attribute should always be in the same state. Since few people will use screen readers with IE9, I
hope this is a satisfactory solution to the problem.

Fixes angular#14892
Fixes angular#14419
Related angular#12731
Narretz added a commit to Narretz/angular.js that referenced this issue Jul 23, 2016
When the select model changes, we add the "selected" attribute to the selected option, so that
screen readers know which option is selected.

Previously, we failed to remove the attribute from the selected / empty option when the model changed
to match a different option, or the unknown / empty option.

When using "track by", the behavior would also show when a user selected an option, and then the
model was changed, because track by watches the tracked expression, and calls the $render function
on change.

This fix reads the current select value, finds the matching option and removes the "selected"
attribute.

IE9 had to be special cased, as it will report option.hasAttribute('selected') === true even
if the option's property and attribute have been unset (even the dev tools show not selected attribute).

I've added a custom matcher that accounts for this behavior. In all other browsers, property and
attribute should always be in the same state. Since few people will use screen readers with IE9, I
hope this is a satisfactory solution to the problem.

Fixes angular#14892
Fixes angular#14419
Related angular#12731
Narretz added a commit to Narretz/angular.js that referenced this issue Jul 23, 2016
When the select model changes, we add the "selected" attribute to the selected option, so that
screen readers know which option is selected.

Previously, we failed to remove the attribute from the selected / empty option when the model changed
to match a different option, or the unknown / empty option.

When using "track by", the behavior would also show when a user selected an option, and then the
model was changed, because track by watches the tracked expression, and calls the $render function
on change.

This fix reads the current select value, finds the matching option and removes the "selected"
attribute.

IE9 had to be special cased, as it will report option.hasAttribute('selected') === true even
if the option's property and attribute have been unset (even the dev tools show not selected attribute).

I've added a custom matcher that accounts for this behavior. In all other browsers, property and
attribute should always be in the same state. Since few people will use screen readers with IE9, I
hope this is a satisfactory solution to the problem.

Fixes angular#14892
Fixes angular#14419
Related angular#12731
Narretz added a commit that referenced this issue Jul 23, 2016
When the select model changes, we add the "selected" attribute to the selected option, so that
screen readers know which option is selected.

Previously, we failed to remove the attribute from the selected / empty option when the model changed
to match a different option, or the unknown / empty option.

When using "track by", the behavior would also show when a user selected an option, and then the
model was changed, because track by watches the tracked expression, and calls the $render function
on change.

This fix reads the current select value, finds the matching option and removes the "selected"
attribute.

IE9 had to be special cased, as it will report option.hasAttribute('selected') === true even
if the option's property and attribute have been unset (even the dev tools show not selected attribute).

I've added a custom matcher that accounts for this behavior. In all other browsers, property and
attribute should always be in the same state. Since few people will use screen readers with IE9, I
hope this is a satisfactory solution to the problem.

Fixes #14892
Fixes #14419
Related #12731
PR (#14894)
Narretz added a commit that referenced this issue Jul 23, 2016
When the select model changes, we add the "selected" attribute to the selected option, so that
screen readers know which option is selected.

Previously, we failed to remove the attribute from the selected / empty option when the model changed
to match a different option, or the unknown / empty option.

When using "track by", the behavior would also show when a user selected an option, and then the
model was changed, because track by watches the tracked expression, and calls the $render function
on change.

This fix reads the current select value, finds the matching option and removes the "selected"
attribute.

IE9 had to be special cased, as it will report option.hasAttribute('selected') === true even
if the option's property and attribute have been unset (even the dev tools show not selected attribute).

I've added a custom matcher that accounts for this behavior. In all other browsers, property and
attribute should always be in the same state. Since few people will use screen readers with IE9, I
hope this is a satisfactory solution to the problem.

Fixes #14892
Fixes #14419
Related #12731
PR (#14894)
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.