I observe the same, especially: ng-show alone works fine, the issue occurs on the element which has both ng-show and ng-class directives
A by-pass could then be to let ng-show alone on a div containing the div with ng-class.

Interesting bug. It ultimately seems to be caused by an interplay of the modal directive and the way ngAnimate handles consecutive animations on the same element. In my tests, the problem will only occur the first time you open the modal. The request for the modal template (details.html) seems to cause a timing issue in some cases, but not always, which causes ngAnimate to join the addClass and removeClass animations, because the addClass animation is still cached on the object, even though it has been executed already.

As a workaround, you can try to put your modal templates into the $templateCache when your application runs. There are grunt plugins for that for example: https://github.com/karlgoldstein/grunt-html2js

I confirm that I was able to recreate in plunker only on the first time. Further attempts of opening modal always work as expected.

On the other hand, in my application where I first noticed this issue it works differently. I can open one of my modals multiple times (without reloading the page) and the issue still occurs.
Maybe I have removed something relevant to the case when isolating the problem into plunker.

Thanks for suggesting grunt-html2js, I'll give it a try.
I don't expect it to fix the issue in my original case (as noted above, it is not only a matter of first modal appearance), but it looks like a reasonable performance improvement anyway.

It would still be interesting if you could create a repro where it fails every time, since we have to create a test for this problem, and it's difficult if there's no 100% repro.

Do you make a network request for the template every time the modal opens or just the first time? Maybe there's more going on in your application at the moment the modal opens?

I don't do anything explicitly in my app to fetch the template every time, so the default angular behavior works there - template is fetched only on the first time and cached afterwards. I've just double checked that in Firebug console.

I do however fetch some additional data via $http request to my REST service in the beginning of my modal controller. The fetched data is then assigned to scope variables which are used in modal template. One of those variables is used in ng-show condition, which is supposed display part of the modal only after data has been fetched.

In the provided plunker I tried to simulate that $http request with a $timeout which assigns value to $scope.loadedData.

I made a small update to the plunker: changed delay in $timeout from 50 ms to 0ms. Now it is 100% recreatable:
http://plnkr.co/edit/vWqR5G1AHE38s4D1rI7Z?p=preview
This time the first appearance of modal works fine (scope variable is updated before template gets fetched) but every further attempt is affected by the defect.

Note: this is still recreatable in FF only (I'm using 38.4.0 ESR). In my Chrome and IE the plunker works as expected.

I have patched angular-animate.js locally with commit 5713231 and it also fixes the issue in my application. 👍

Good stuff! We'll have to double-check if that isn't breaking other stuff. I totally read over the fact that this is mainly a FF issue. Seems to be an implementation issue with how a requestAnimationFrame is triggered.

It's not only a FF issue. It seems to be very tricky with browsers.

The original issue found in my app was observable in Chrome only. Then I tried to isolate a test case and created the plunker example.. and to my surprise I was able to recreate the issue with plunker on FF only.

So it seems that the issue affects different browsers, depending on case. However the root cause seems to be the same, because your fix also fixes the issue I observed in my app on Chrome.

I think I experienced exactly this bug using the following setup:

ionic 1.2.1-nightly-1867 (ionic 1.2.1 stable bower name)
angular 1.4.3
angular-animate 1.4.3

it's 100% reproducible in Chrome/Android and Chrome/Windows in a a timeout-scenario but not reproducible at all without timeout.

Using ng-if instead seems to solve the bug.

@jakub-g This should be fixed in latest 1.4 (1.4.9). You are using an outdated version. If the problem persists in the new version, please open a new issue.