angular.js/test/ng, branch v1.2.0-rc.3 fix($compile): abort compilation when duplicate element transclusion 2013-10-12T00:12:24+00:00 Igor Minar 2013-10-11T04:35:54+00:00 63c5334c84b7269428c710226764d1f08a36e0d4 Issue an error and abort compilation when two directives that ask for transclusion are found on a single element. This configuration is not supported and we previously failed to issue the error because in the case of element transclusion the compilation is re-started and this caused the compilation context to be lost. The ngRepeat directive has been special-cased to bypass this warning because it knows how to handle this scenario internally. This is not an ideal solution to the problem of multiple transclusions per element, we are hoping to have this configuration supported by the compiler in the future. See #4357. Closes #3893 Closes #4217 Closes #3307 
Issue an error and abort compilation when two directives that ask for transclusion are found
on a single element. This configuration is not supported and we previously failed to issue
the error because in the case of element transclusion the compilation is re-started and this
caused the compilation context to be lost.

The ngRepeat directive has been special-cased to bypass this warning because it knows how to
handle this scenario internally.

This is not an ideal solution to the problem of multiple transclusions per element, we are
hoping to have this configuration supported by the compiler in the future. See #4357.

Closes #3893
Closes #4217
Closes #3307
refactor(location): $location now uses urlUtils, not RegEx 2013-10-10T18:41:07+00:00 Jeff Cross 2013-07-25T17:53:43+00:00 b019a48bb1176f3c9ce29b628a321b6ffe873393 The location service, and other portions of the application, were relying on a complicated regular expression to get parts of a URL. But there is already a private urlUtils provider, which relies on HTMLAnchorElement to provide this information, and is suitable for most cases. In order to make urlUtils more accessible in the absence of DI, its methods were converted to standalone functions available globally. The urlUtils.resolve method was renamed urlResolve, and was refactored to only take 1 argument, url, and not the 2nd "parse" boolean. The method now always returns a parsed url. All places in code which previously wanted a string instead of a parsed url can now get the value from the href property of the returned object. Tests were also added to ensure IPv6 addresses were handled correctly. Closes #3533 Closes #2950 Closes #3249 
The location service, and other portions of the application,
were relying on a complicated regular expression to get parts of a URL.
But there is already a private urlUtils provider,
which relies on HTMLAnchorElement to provide this information,
and is suitable for most cases.

In order to make urlUtils more accessible in the absence of DI,
its methods were converted to standalone functions available globally.

The urlUtils.resolve method was renamed urlResolve,
and was refactored to only take 1 argument, url,
and not the 2nd "parse" boolean.
The method now always returns a parsed url.
All places in code which previously wanted a string instead of a parsed
url can now get the value from the href property of the returned object.

Tests were also added to ensure IPv6 addresses were handled correctly.

Closes #3533
Closes #2950
Closes #3249
feat(ngRepeat): use block separator comments 2013-10-09T22:19:10+00:00 jankuca 2013-09-23T18:24:42+00:00 9efa46ae640cde17487c341daa9a75c0bd79da02 Issue: multi-elements ng-repeat (ng-repeat-start, ng-repeat-end) can contain elements with a trancluding directive. This directive changes content of the row (template) and ng-repeat does not work correctly (when removing/moving rows), because ng-repeat works with the original template (elements). This changes ng-repeat behavior to traverse the DOM to find current elements everytime we are moving/removing rows (if the template has multiple elements). Closes #3104 
Issue: multi-elements ng-repeat (ng-repeat-start, ng-repeat-end) can contain elements with a trancluding directive. This directive changes content of the row (template) and ng-repeat does not work correctly (when removing/moving rows), because ng-repeat works with the original template (elements).

This changes ng-repeat behavior to traverse the DOM to find current elements everytime we are moving/removing rows (if the template has multiple elements).

Closes #3104
revert: fix($parse): handle promises returned from parsed function calls 2013-10-09T22:15:43+00:00 Igor Minar 2013-10-09T16:54:10+00:00 b6a37d112b3e1478f4d14a5f82faabf700443748 This reverts commit 3a65822023119b71deab5e298c7ef2de204caa13. The change cased regressions in third party components that require promises from getter functions not to be unwrapped. Since we have deprecated the promise unwrapping support in $parse it doesn't make much sense to fix this issue and deal with regressions in third party code. Closes #4158 
This reverts commit 3a65822023119b71deab5e298c7ef2de204caa13.

The change cased regressions in third party components that require
promises from getter functions not to be unwrapped.

Since we have deprecated the promise unwrapping support in $parse it
doesn't make much sense to fix this issue and deal with regressions in
third party code.

Closes #4158
fix($parse): deprecate promise unwrapping and make it an opt-in 2013-10-09T22:15:43+00:00 Igor Minar 2013-10-07T16:58:37+00:00 5dc35b527b3c99f6544b8cb52e93c6510d3ac577 This commit disables promise unwrapping and adds $parseProvider.unwrapPromises() getter/setter api that allows developers to turn the feature back on if needed. Promise unwrapping support will be removed from Angular in the future and this setting only allows for enabling it during transitional period. If the unwrapping is enabled, Angular will log a warning about each expression that unwraps a promise (to reduce the noise, each expression is logged only onces). To disable this logging use `$parseProvider.logPromiseWarnings(false)`. Previously promises found anywhere in the expression during expression evaluation would evaluate to undefined while unresolved and to the fulfillment value if fulfilled. This is a feature that didn't prove to be wildly useful or popular, primarily because of the dichotomy between data access in templates (accessed as raw values) and controller code (accessed as promises). In most code we ended up resolving promises manually in controllers or automatically via routing and unifying the model access in this way. Other downsides of automatic promise unwrapping: - when building components it's often desirable to receive the raw promises - adds complexity and slows down expression evaluation - makes expression code pre-generation unattractive due to the amount of code that needs to be generated - makes IDE auto-completion and tool support hard - adds too much magic BREAKING CHANGE: $parse and templates in general will no longer automatically unwrap promises. This feature has been deprecated and if absolutely needed, it can be reenabled during transitional period via `$parseProvider.unwrapPromises(true)` api. Closes #4158 Closes #4270 
This commit disables promise unwrapping and adds
$parseProvider.unwrapPromises() getter/setter api that allows developers
to turn the feature back on if needed. Promise unwrapping support will
be removed from Angular in the future and this setting only allows for
enabling it during transitional period.

If the unwrapping is enabled, Angular will log a warning about each
expression that unwraps a promise (to reduce the noise, each expression
is logged only onces). To disable this logging use
`$parseProvider.logPromiseWarnings(false)`.

Previously promises found anywhere in the expression during expression
evaluation would evaluate to undefined while unresolved and to the
fulfillment value if fulfilled.

This is a feature that didn't prove to be wildly useful or popular,
primarily because of the dichotomy between data access in templates
(accessed as raw values) and controller code (accessed as promises).

In most code we ended up resolving promises manually in controllers
or automatically via routing and unifying the model access in this way.

Other downsides of automatic promise unwrapping:

- when building components it's often desirable to receive the
  raw promises
- adds complexity and slows down expression evaluation
- makes expression code pre-generation unattractive due to the
  amount of code that needs to be generated
- makes IDE auto-completion and tool support hard
- adds too much magic

BREAKING CHANGE: $parse and templates in general will no longer
automatically unwrap promises. This feature has been deprecated and
if absolutely needed, it can be reenabled during transitional period
via `$parseProvider.unwrapPromises(true)` api.

Closes #4158
Closes #4270
test(filters): fix timezone-dependent test 2013-10-09T17:18:51+00:00 Brian Ford 2013-10-08T21:40:44+00:00 1366556ace3e71f9e4abe63554050ddf9c0dabb6 Closes #4218 
Closes #4218
fix(input): `false` is no longer an empty value by default 2013-10-07T23:47:51+00:00 Pete Bacon Darwin 2013-09-25T11:49:55+00:00 b56b21a898b3c77589a48a290271f9dc181dafe8 `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 
`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
feat($interval): add a service wrapping setInterval 2013-10-07T20:45:40+00:00 Julie 2013-09-13T19:47:05+00:00 2b5ce84fca7b41fca24707e163ec6af84bc12e83 The $interval service simplifies creating and testing recurring tasks. This service does not increment $browser's outstanding request count, which means that scenario tests and Protractor tests will not timeout when a site uses a polling function registered by $interval. Provides a workaround for #2402. For unit tests, repeated tasks can be controlled using ngMock$interval's tick(), tickNext(), and tickAll() functions. 
The $interval service simplifies creating and testing recurring tasks.
This service does not increment $browser's outstanding request count,
which means that scenario tests and Protractor tests will not timeout
when a site uses a polling function registered by $interval. Provides
a workaround for #2402.

For unit tests, repeated tasks can be controlled using ngMock$interval's
tick(), tickNext(), and tickAll() functions.
fix(*): protect calls to hasOwnProperty in public API 2013-10-07T16:01:13+00:00 Peter Bacon Darwin 2013-10-05T09:49:09+00:00 7a586e5c19f3d1ecc3fefef084ce992072ee7f60 Objects received from outside AngularJS may have had their `hasOwnProperty` method overridden with something else. In cases where we can do this without incurring a performance penalty we call directly on Object.prototype.hasOwnProperty to ensure that we use the correct method. Also, we have some internal hash objects, where the keys for the map are provided from outside AngularJS. In such cases we either prevent `hasOwnProperty` from being used as a key or provide some other way of preventing our objects from having their `hasOwnProperty` overridden. BREAKING CHANGE: Inputs with name equal to "hasOwnProperty" are not allowed inside form or ngForm directives. Before, inputs whose name was "hasOwnProperty" were quietly ignored and not added to the scope. Now a badname exception is thrown. Using "hasOwnProperty" for an input name would be very unusual and bad practice. Either do not include such an input in a `form` or `ngForm` directive or change the name of the input. Closes #3331 
Objects received from outside AngularJS may have had their `hasOwnProperty`
method overridden with something else. In cases where we can do this without
incurring a performance penalty we call directly on Object.prototype.hasOwnProperty
to ensure that we use the correct method.

Also, we have some internal hash objects, where the keys for the map are provided
from outside AngularJS. In such cases we either prevent `hasOwnProperty` from
being used as a key or provide some other way of preventing our objects from
having their `hasOwnProperty` overridden.

BREAKING CHANGE: Inputs with name equal to "hasOwnProperty" are not allowed inside
form or ngForm directives.

Before, inputs whose name was "hasOwnProperty" were quietly ignored and not added
to the scope.  Now a badname exception is thrown.

Using "hasOwnProperty" for an input name would be very unusual and bad practice.
Either do not include such an input in a `form` or `ngForm` directive or change
the name of the input.

Closes #3331
 fix(rootScope): make stopPropagation only stop its own event 2013-10-05T21:45:43+00:00 Pete Bacon Darwin 2013-10-05T21:45:43+00:00 47f7bd706efc5f2944d182e46c1b1d324298ff36 All sibling event handlers residing on the same scope to were stopped if one of them called stopPropagation. Closes #4204 
All sibling event handlers residing on the same scope to were stopped
if one of them called stopPropagation.

Closes #4204