fix(select): do not break when removing the element (e.g. via ngIf)

[gkalpak]

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 removing <option> elements, we schedule some operations on the ngModelCtrl. For performance reasons, these operation are scheduled to be run as a post-digest operation. If the <select> element happens to be removed as well (and its scope destroyed), an error may be thrown due to certain values not being available on the $scope.
See #15466.

What is the new behavior (if this is a feature change)?
Nothing breaks.

Does this PR introduce a breaking change?
No.

Please check if the PR fulfills these requirements

• The commit message follows our guidelines: https://github.com/angular/angular.js/blob/master/CONTRIBUTING.md#commit-message-format
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

Other information:
Fixes #15466.

[dcherman]

Could you use the $$destroyed property of the scope rather than tracking the state with a sentinel var?

[gkalpak]

Yes, I could. But since we were already having a $destroy callback I opted for using that instead of the $$destroy as it seems unnecssary. Can go either way.

[petebacondarwin]

If $$destroyed would work then I would prefer that. It is one less thing to store in memory and keep track of in maintenance of the code.

[Narretz]

Does the app actually break when the select is removed, or does it just throw? I mean, is there some cleanup that is not performed? I think the commit message should reflect that more precisely.

[gkalpak]

@Narretz, not sure what you mean. An error is thrown in the middle of a digest. Whether that breaks an app depends on what was going on during that digest, what watchers were skipped due to the error etc.

[gkalpak]

BTW, the particular error in #15466 is caused by this line: When a previously selected option element is destroyed, we schedule to re-read the select's value asynchronously. Since destroying the select itself also destroys its option children, it triggers this check (which then fails because the scope has been destroyed already.
But similar problems would arise whenever we call scheduleViewValueUpdate() and the select is destroyed before the $$postDigest phase, so guarding against it inside scheduleViewValueUpdate's $postDigest callback seems appropriate.

[Narretz]

@gkalpak In the middle of a digest? It throws in $$postDigest, no?

[gkalpak]

Yeah, sorry, I meant $$postDigest. So, whether the app breaks, depends on what tasks are still pending in the postDigestQueue 😁

[gkalpak]

Aha, I see your point. I just realized it only breaks if the $exceptionHandler rethrows. I will change the wording to "not throw".

[petebacondarwin]

LGTM