Due to an earlier change, ngModelWatch() no longer returns a value to the
caller. This means the digest loop has no way to tell if the watch actually
modified anything and so can not schedule another pass.
This means any watches that watch form or model controller changes
(e.g. watches on form.$valid) that are scheduled prior to an ngModelWatch()
will not be able to see any changes made therin.
This commit fixes this behavior by returning the latest evaluated ng-model
value.
Closes#5258Closes#5282
Although modern browser support the "input" event, they still only fire
the "change" event when they auto complete form elements
other than the currently selected one.
Related to #1460
$setViewValue does not really "Read a value from view".
It should be called to trigger the ngModel to be updated when the value in the view changes.
Closes#4907
Due to animations, DOM might get destroyed much later than scope and so the element $destroy event
might get fired outside of $digest, which causes changes to the validation model go unobserved
until the next digest. By deregistering on scope event, the deregistration always happens
in $digest and the form validation model changes will be observed.
Closes#4226Closes#4779
`checkboxInputType` and `ngList` directives need to have special logic for whether
they are empty or not. Previously this had been hard coded into their
own directives or the `ngRequired` directive. This made it difficult to handle
these special cases.
This change factors out the question of whether an input is empty into a method
`$isEmpty` on the `ngModelController`. The `ngRequired` directive now uses this
method when testing for validity and directives, such as `checkbox` or `ngList`
can override it to apply logic specific to their needs.
Closes#3490, #3658, #2594
previously the compile/link fns executed in this order controlled via priority:
- CompilePriorityHigh, CompilePriorityMedium, CompilePriorityLow
- PreLinkPriorityHigh, PreLinkPriorityMedium, PreLinkPriorityLow
- link children
- PostLinkPriorityHigh, PostLinkPriorityMedium, PostLinkPriorityLow
This was changed to:
- CompilePriorityHigh, CompilePriorityMedium, CompilePriorityLow
- PreLinkPriorityHigh, PreLinkPriorityMedium, PreLinkPriorityLow
- link children
- PostLinkPriorityLow, PostLinkPriorityMedium , PostLinkPriorityHigh
Using this order the child transclusion directive that gets replaced
onto the current element get executed correctly (see issue #3558),
and more generally, the order of execution of post linking function
makes more sense. The incorrect order was an oversight that has
gone unnoticed for many suns and moons.
(FYI: postLink functions are the default linking functions)
BREAKING CHANGE: the order of postLink fn is now mirror opposite of
the order in which corresponding preLinking and compile functions
execute.
Very few directives in practice rely on order of postLinking function
(unlike on the order of compile functions), so in the rare case
of this change affecting an existing directive, it might be necessary
to convert it to a preLinking function or give it negative priority
(look at the diff of this commit to see how an internal attribute
interpolation directive was adjusted).
Closes#3558
The input field email regex does't not match long domain extensions. This commit extends the email regexp to take a 6 character TLD.
Example 6-character TLDs include .museum and .travel - (e.g. allabout.travel).
The input [number] error spans did not show on the example, as they were
relying on an non-existing property (myForm.list.$error) vs the working
property (myForm.input.$error)
jQuery switched to a completely new event binding implementation as of
1.7.0, centering around on/off methods instead of previous bind/unbind.
This patch makes jqLite match this implementation while still supporting
previous bind/unbind methods.
In IE the model is not updated when the input value is modified using the context
menu, e.g. pasting from the clipboard, or cutting all or part of the current value.
To capture these changes, we bind to the proprietary 'paste' and 'cut' events.
Closes#1462
In cases when we reuse elements in a repeater but associate
them with a new scope (see #933 - repeating over array of
primitives) it's possible for the internal ngModel state and
the scope state to get out of sync. This change ensure that
the two are always sync-ed up even in cases where we
reassociate an element with a different (but similar) scope.
In the case of repeating over array of primitives it's still
possible to run into issue if we iterate over primitives and
use form controls or similar widgets without ngModel - oh well,
we'd likely need a special repeater for primitives to deal
with this properly, even then there might be cornercases.
Closes#933
