fix($parse): fix CSP nested property evaluation, and issue that prevente...

[dozingcat]

...d its tests from failing

cspSafeGetterFn incorrectly returned undefined if any of its key parameters were undefined. This
wasn't caught by the $parse unit tests because of a timing problem where $ParseProvider was reading the CSP flag before the tests manually set it, so the CSP property evaluation tests never ran. Add
test that verifies evaluation of nested properties of multiple lengths.

Fixes #5591

[caitp]

Look at this line (897)... Now look at the one below it...

What we're doing here is this: if the path key is not present, and there is another path key after it, we always want to return undefined.

If there are problems with the existing algorithm, we'll need to fix it, but to undo that would be essentially reverting a desirable fix. Lets find a better solution for the csp issue.

I'm fairly sure that this changeset would have broken tests if the test suite for the changeset fixing #5442 / #2249 didn't get shrunk down, with a few test cases removed

Even if it doesn't break tests, we can make this more concise and not breaking the logic mentioned above by combining it into the second if statement

[dozingcat]

I think that's a separate issue. As I understand it given scope.a={b: null}, $eval('a.b') should return null and $eval('a.b.c') should return undefined. This changeset doesn't modify that behavior. It addresses the case where cspSafeGetterFn is called with an expression of 'a.b.c', so the key3 and key4 parameters are undefined. pathVal then becomes undefined after evaluating pathVal[key3], unless we check for the key being undefined first.

[caitp]

At the very least, it does duplicate functionality, and this could be made much more concise.

An 8 byte change || !key1 would have the same impact, and absolutely avoid breaking logic

Good catch on the csp test fixes, though

[dozingcat]

Moved key checks to existing if statements as suggested.

[caitp]

Hmm, on the other hand.. Maybe something more like

if (!key1) return pathVal;
else if (pathVal == null) return undefined;

might be cleaner / easier to read, and possibly save a comparison. Although it still technically violates the style guide.

I contradict myself a lot, you'll get used to it ;) I just want to avoid duplicating code, and try to keep it readable and straight forward

[dozingcat]

I like that better too, the conditions are basically independent. If I drop the "else" I don't think it violates the style guide, since it references Google's JS style guide, which "follow[s] the C++ formatting rules in spirit", which says "Short conditional statements may be written on one line if this enhances readability." (Yay indirection). And there are several other occurrences of "if (...) return ..." in the Angular source.

Of course the most readable and concise implementation would be to iterate over the array of path components directly, but playing with jsperf showed about a 35% performance hit, which is presumably why it's unrolled into keyN parameters.

[caitp]

I'm still not sure about this though, it seems weird to read this every time $parse is called. If it's the best we can do then that's one thing, but is there not a better solution?

[dozingcat]

How about this? Setting document.securityPolicy.isActive makes the $sniffer service see that CSP is enabled at injection time (via the csp() function in Angular.js). It's a bit ugly to mess with a global object like that, but maybe in a test it's ok. The "proper" solution might be to have a CSP detection service which could be mocked in tests, but that seems like overkill.

Incidentally the promise logging tests were never enabling CSP mode; that's now fixed.

[caitp]

Messing with the global variable seems a bit worrisome --- But let's see what other folks say about it... Probably won't hear much this week, but next week is a possibility

[IgorMinar]

I reviewed it and this is a really nice PR. Thanks for all the work @dozingcat

I squashed the changes, added an afterEach to restore the global state and I'm testing this all on the CI right now.

I'll merge it and sync it into google today