Don't call $window.getComputedStyle on non-element

[ksperling]

This throws an exception at least in some versions of FF, and is declared
as taking only an Element and not an arbitrary Node in the W3C spec.

One place where this can happen easily is with ng-view if the template
contains more than just a single top-level node (even just a trailing
newline can trigger the problem).

Also short-circuit the case where getComputedStyle doesn't return anything.

[cburgdorf]

Cloud be related to #2400

[ksperling]

Ah yes, that's the one (I'm on a different machine with a different version of FF at the moment, so couldn't reproduce the exact error)

[petebacondarwin]

• Contributor signed CLA now or in the past (if you just signed, leave a comment here with your real name)
• PR doesn't introduce new api
• PR doesn't contain a breaking change
• PR contains unit tests
• PR contains e2e tests (if suitable)
• PR contains documentation update (if suitable)
• PR passes all tests on Travis (sanity)
• PR passes all tests on ci.angularjs.org (cross-browser compatibility)
• PR is rebased against recent master
• PR is squashed into one commit per logical change
• PR's commit messages are descriptive and allows us to autogenerate release notes (required commit message format)
• All changes requested in review have been implemented

[petebacondarwin]

@ksperling - Thanks for providing this bug fix. Can you take a look at the check-list above and address those items that have not been ticked?

[ksperling]

I've just signed the CLA (Karsten Sperling).
This is not a breaking change.
The commit should already be against a recent master.

Writing an e2e test that fails before this change and passes with it sounds rather complicated, is that really warranted for a tiny fix like this?

[petebacondarwin]

Nice one Karsten! Thanks.
BTW it is a pain but the commit first line description should start with a lowercase letter. Don't worry about fixing that.

It would be really great to get a failing unit test in before merging. A strategy could be to apply a Jasmine spy to the getComputedStyle function and check that it is not called if a non-element is passed to animator.

[cburgdorf]

Hey @petebacondarwin any chance you can also look into this (#2381) one? It's related code wise so I wonder if I should go ahead and rebase against this PR.

[petebacondarwin]

@ksperling - I tried a test like this but this actually blows up before it even gets to the call to getComputedStyle as it tries to call .css() on the non-element. This makes me wonder exactly what kind of node needs to be passed in to cause it to fail as it does in FF?

    it('should not call window.getComputedStyle if `element` is not a DOM element', 
      inject(function($animator, $window, $rootScope, $sniffer) {
        spyOn($window,'getComputedStyle');
        if ($sniffer.supportsTransitions) {
          var animator = $animator($rootScope, { ngAnimate : '{show: \'inline-show\'}' });
          var node = angular.element(document.createTextNode('Dummy'));
          body.append(node);
          animator.show(node);
          expect($window.getComputedStyle).not.toHaveBeenCalled();
        }
    }));

[petebacondarwin]

It seems that this was fixed at 9956bae#L0R278