This repository has been archived by the owner on Apr 12, 2024. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 27.5k
fix(ngOptions): do not unset the selected
property unless necessary
#15478
Closed
gkalpak
wants to merge
2
commits into
angular:master
from
gkalpak:fix-ngOptions-avoid-resetting-selected
Closed
fix(ngOptions): do not unset the selected
property unless necessary
#15478
gkalpak
wants to merge
2
commits into
angular:master
from
gkalpak:fix-ngOptions-avoid-resetting-selected
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Previously, when updating the value of a `select[multiple]` element, all options were first set to `selected = false` and then the selected ones were set to `true`. By setting an already selected option to `selected = false` and then `true` again - essentially unselecting and reselecting it - caused some browsers (including Firefox, IE and under some circumstances Chrome) to unexpectedly scroll to the last selected option. This commit fixes it by ensuring that the `selected` property is only set if its current value is different than the new one and even then it is set to its final value at once (i.e. without first setting it to `false`), thus avoiding the undesirable behavior. Fixes angular#15477
Narretz
reviewed
Dec 15, 2016
@@ -506,16 +506,16 @@ var ngOptionsDirective = ['$compile', '$document', '$parse', function($compile, | |||
} else { | |||
|
|||
selectCtrl.writeValue = function writeNgOptionsMultiple(value) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you change the parameter name to values? Since it's an array if it's defined. This also makes it easier to understand with map
below.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
LGTM |
I restarted the unit test job, there were some mobile safari tests for animateCss, they looked unrelated |
gkalpak
added a commit
that referenced
this pull request
Dec 19, 2016
Previously, when updating the value of a `select[multiple]` element, all options were first set to `selected = false` and then the selected ones were set to `true`. By setting an already selected option to `selected = false` and then `true` again - essentially unselecting and reselecting it - caused some browsers (including Firefox, IE and under some circumstances Chrome) to unexpectedly scroll to the last selected option. This commit fixes it by ensuring that the `selected` property is only set if its current value is different than the new one and even then it is set to its final value at once (i.e. without first setting it to `false`), thus avoiding the undesirable behavior. Fixes #15477 Closes #15478
1 task
ellimist
pushed a commit
to ellimist/angular.js
that referenced
this pull request
Mar 15, 2017
Previously, when updating the value of a `select[multiple]` element, all options were first set to `selected = false` and then the selected ones were set to `true`. By setting an already selected option to `selected = false` and then `true` again - essentially unselecting and reselecting it - caused some browsers (including Firefox, IE and under some circumstances Chrome) to unexpectedly scroll to the last selected option. This commit fixes it by ensuring that the `selected` property is only set if its current value is different than the new one and even then it is set to its final value at once (i.e. without first setting it to `false`), thus avoiding the undesirable behavior. Fixes angular#15477 Closes angular#15478
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)
Bug fix.
What is the current behavior? (You can also link to an open issue here)
When updating the value of a
select[multiple]
element, all options are first set toselected = false
and then the selected ones are set totrue
. By setting an already selected option toselected = false
and thentrue
again - essentially unselecting and reselecting it - causes some browsers (including Firefox, IE and under some circumstances Chrome) to unexpectedly scroll to the last selected option.What is the new behavior (if this is a feature change)?
The
selected
property of the<option>
elements is only set if its current value is different than the new one and even then it is set to its final value at once (i.e. without first setting it tofalse
), thus avoiding the undesirable behavior.Does this PR introduce a breaking change?
No.
Please check if the PR fulfills these requirements
Docs have been added / updated (for bug fixes / features)Other information:
Fixes #15477