Logical operators return incorrect results when used on forgiving expressions.

[georeith]

Version: 1.4.0-rc.2

Given the following statements:

• scope.$eval("true && does.not.exist");
• scope.$eval("true && !does.not.exist");

Both return true, as long as does.not is not an object on the current scope.

However scope.$eval("true && doesnotexist"); and scope.$eval("true && undefined"); both return false as expected as long as doesnotexist is not a truthy value on the current scope.

This makes me think it has something to do with using scope.$parse as it only occurs when attempting to access nested properties of undefined values on the scope which scope.$parse suppresses errors for.

For this reason any directive such as ng-if and ng-switch. For examples see: http://jsbin.com/muqaviwesu/1/edit?html,js,output

[ExplodingCabbage]

Another example, using "forgiving" function calls: scope.$eval("true && doesnotexist()"); returns true.

I guess that in general this weird behaviour happens when using boolean operators on the results of "forgiving" expressions. But nothing in the docs about forgiving expressions suggests that this behaviour should occur, and it's bizarre; it's a violation of the simple mental model of "calling undefined as a function or accessing properties of undefined returns undefined" that the docs give us.

Of course, any fix to this will be a breaking change, but it seems like a clear bug.

[lgalfaso]

The issues originally posted are fixed as part of d19504a the other is a real issue. Should have a patch soon

[Narretz]

@lgalfaso are you sure the first issue has been fixed? In the jsbin, the first ng-if for 'AND' should evaluate to undefined, i.e. be not visible. This doesn't work with the snapshot, but it does work in 1.3.16

[lgalfaso]

Mmm.. @Narretz you are right, updated the PR to fix

• true && a.b.c
• true && a()
• true && a()()
• false || a.b.c
• false || a()
• false || a()()

where a == null

These are all small variations of the same issue, hopefully this should fix all the variations

[ExplodingCabbage]

@lgalfaso just a note - although @georeith gave the example of true && a.b.c, the same bug occurs for just true && a.b if a is null. I notice that your commit message refers to the a.b.c form but not the a.b form; I don't know whether you've in fact fixed both.

[lgalfaso]

@ExplodingCabbage they are all fixed, in fact we have tests for

• true && a
• true && a()
• true && a()()
• true && a.b
• true && a.b.c
• false || a
• false || a()
• false || a()()
• false || a.b
• false || a.b.c