angular.js/test/ng, branch v1.2.4 fix($compile): update cloned elements if the template arrives after the cloning 2013-12-06T06:16:25+00:00 Tobias Bosch 2013-11-27T03:55:02+00:00 b0972a2e75909e41dbac6e4413ada7df2d51df3a If an element has a directive whose content is loaded using `templateUrl`, and the element is cloned using a linking function before the template arrives, the clone needs to be updated as well. This also updates `ngIf` and `ngRepeat` to keep the connection to the clone of a tranclude function, so that they know about the changes a directive with `templateUrl` does to the element in the future. Fixes to #4930. 
If an element has a directive whose content is loaded using `templateUrl`,
and the element is cloned using a linking function before the template arrives,
the clone needs to be updated as well.

This also updates `ngIf` and `ngRepeat` to keep the connection to the clone
of a tranclude function, so that they know about the changes a directive with
`templateUrl` does to the element in the future.

Fixes to #4930.
chore(Scope): short-circuit after dirty-checking last dirty watcher 2013-12-05T23:37:37+00:00 Karl Seamon 2013-12-04T00:16:08+00:00 d070450cd2b3b3a3aa34b69d3fa1f4cc3be025dd Stop dirty-checking during $digest after the last dirty watcher has been re-checked. This prevents unneeded re-checking of the remaining watchers (They were already checked in the previous iteration), bringing a substantial performance improvement to the average case run time of $digest. Closes #5272 Closes #5287 
Stop dirty-checking during $digest after the last dirty watcher has been re-checked.

This prevents unneeded re-checking of the remaining watchers (They were already
checked in the previous iteration), bringing a substantial performance improvement
to the average case run time of $digest.

Closes #5272
Closes #5287
fix(ngInit): evaluate ngInit before ngInclude 2013-12-05T07:26:56+00:00 Caitlin Potter 2013-11-30T02:02:00+00:00 0e50810c53428f4c1f5bfdba9599df54cb7a6c6e The priority of ngInit is adjusted to occur before ngInclude, and after ngController. This enables ngInit to initiallize values in a controller's scope, and also to initiallize values before ngInclude executes. Closes #5167 Closes #5208 
The priority of ngInit is adjusted to occur before ngInclude, and after
ngController. This enables ngInit to initiallize values in a controller's
scope, and also to initiallize values before ngInclude executes.

Closes #5167
Closes #5208
fix(input): ensure ngModelWatch() triggers second digest pass when appropriate 2013-12-05T06:49:11+00:00 Daniel Tabuenca 2013-12-05T00:25:49+00:00 b6d5439343b9801f7f2a009d0de09cba9aa21a1d 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 #5258 Closes #5282 
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 #5258
Closes #5282
fix($rootScope): broadcast $destroy event on $rootScope 2013-12-04T23:29:19+00:00 Jeff Cross 2013-12-04T22:33:58+00:00 d802ed1b3680cfc1751777fac465b92ee29944dc Fixes #5169 
Fixes #5169
fix($rootScope): clear phase if an exception is raised by a watcher 2013-12-04T18:11:29+00:00 Thomas Guillory 2013-11-06T14:01:10+00:00 d3c486dd6dfa8d5dca32a3e28aa685fb7260c878 Add calls to clearPhase() when an exception is raised by a watcher while a digest cycle, in order to not be stuck on `$digest` scope phase 
Add calls to clearPhase() when an exception is raised by a watcher
while a digest cycle, in order to not be stuck on `$digest` scope phase
fix($compile): ensure isolated local watches' lastValue is always in sync 2013-12-04T17:45:20+00:00 Daniel Tabuenca 2013-11-28T06:01:22+00:00 2d0f6ccba896fe34141d6d4f59eef6fba580c5c2 When using two-way binding with isolate scope, under some circumstances the lastValue variable captured in the parentValueWatch function can get out of sync. Specifically, if both the value in the origin scope as well as the value in the isolate scope get independently updated to the same value within one digest cycle, the lastValue is never updated. This potentially causes the watch to make the wrong decision as to which side to update on subsequent passes. This fixes things by ensuring lastValue is always set to the last seen value even if the watch's logic was short circuited because there was no difference between the values in the original and isolate scopes. Closes #5182 
When using two-way binding with isolate scope, under some circumstances
the lastValue variable captured in the parentValueWatch function can get
out of sync.

Specifically, if both the value in the origin scope as well as the value
in the isolate scope get independently updated to the same value within
one digest cycle, the lastValue is never updated. This potentially causes
the watch to make the wrong decision as to which side to update on subsequent
passes.

This fixes things by ensuring lastValue is always set to the last seen
value even if the watch's logic was short circuited because there was no
difference between the values in the original and isolate scopes.

Closes #5182
refactor($location): move file://+win path fix to $location 2013-11-27T02:31:27+00:00 Jeff Cross 2013-11-26T19:36:36+00:00 736c8fbbae57a209f4ba570e38cc3bd0745a9569 The urlResolve method was fixed to automatically remove the volume label from path names to fix issues with the file protocol on windows where $location.path() was returning paths where the first segment would be the volume name, such as "/C:/mypath". See #4942 and #4928 However, the solution was specific to the $location non- HTML5 mode, and was implemented at a lower level of abstraction than it should have been. This refactor moves the fix to inside of the LocationHashBangUrl $$parse method. Closes #5041 
The urlResolve method was fixed to automatically remove the
volume label from path names to fix issues with the file
protocol on windows where $location.path() was returning
paths where the first segment would be the volume name,
such as "/C:/mypath". See #4942 and #4928

However, the solution was specific to the $location non-
HTML5 mode, and was implemented at a lower level of
abstraction than it should have been. This refactor moves
the fix to inside of the LocationHashBangUrl $$parse method.

Closes #5041
fix($sanitize): Use same whitelist mechanism as $compile does. 2013-11-26T22:29:38+00:00 Tobias Bosch 2013-11-25T23:40:18+00:00 333523483f3ce6dd3177b697a5e5a7177ca364c8 `$sanitize` now uses the same mechanism as `$compile` to validate uris. By this, the validation in `$sanitize` is more general and can be configured in the same way as the one in `$compile`. Changes - Creates the new private service `$$sanitizeUri`. - Moves related specs from `compileSpec.js` into `sanitizeUriSpec.js`. - Refactors the `linky` filter to be less dependent on `$sanitize` internal functions. Fixes #3748. 
`$sanitize` now uses the same mechanism as `$compile` to validate uris.
By this, the validation in `$sanitize` is more general and can be
configured in the same way as the one in `$compile`.

Changes
- Creates the new private service `$$sanitizeUri`.
- Moves related specs from `compileSpec.js` into `sanitizeUriSpec.js`.
- Refactors the `linky` filter to be less dependent on `$sanitize`
  internal functions.

Fixes #3748.
chore($httpBackend): preserve original non-zero http status code for file:// apps 2013-11-26T20:36:41+00:00 corrupt 2013-10-18T12:42:55+00:00 68ceb17272bdd2ebc838565070973d93704f4427 Previously if an app was running from file:// origin we would always return either http 200 or 404 depending on whether the response was present. This changes the behavior so that we do this only if the protocol of the request (not the origin) is file:// and only if the status code is 0. Closes #4436 Closes #4587 Closes #4514 
Previously if an app was running from file:// origin we would always return either
http 200 or 404 depending on whether the response was present.

This changes the behavior so that we do this only if the protocol of the request
(not the origin) is file:// and only if the status code is 0.

Closes #4436
Closes #4587
Closes #4514