Flicker in IE (11) and Opera (12) and content moved downwards in IE (11)

[freeboarder]

In Internet Explorer (11) and Opera (12) the dialog sometimes is displayed again for a split second after it was closed. This can be reproduced even on the demo page (http://likeastore.github.io/ngDialog/#) when playing around a bit. Another issue is that the content of the view the dialog is displayed on is shifted a bit downwards, at least in IE 11 (not in Firefox, Chrome or Opera).

[freeboarder]

Found a solution for the page move problem: It's obviously a bug in the IE: If margin-top for the body is set to a value other than 0 the page shifts obviously according to the margin if overflow is set to 'hidden' (that's done by ngDialog when the dialog is displayed). The workaround would be to set margin-top of the body to 0.

[voronianski]

@freeboarder glad to hear that you managed to fix the issue.

I would like to advice you to use one of the css resets in order to be on the same page and safe side in every browser - http://necolas.github.io/normalize.css/ http://meyerweb.com/eric/tools/css/reset

[freeboarder]

Bummer that you closed the issue so early. The flicker problem is not solved yet. And to be honest: Since IE is a very important browser it gets in the way of using ngDialog on (professional) websites that have a sophisticated layout/design. Normalize.css and Reset did not help in that matter. I am sure that it is a CSS problem in IE that could be fixed somehow.

[charlespockert]

FYI I can reproduce this in IE (Chrome is fine) but occasionally (once every 50 or so closes) it causes the "flickering" dialog to stay on screen and become unresponsive so that it can't be closed by any means (I assume it's lost any bindings it once had). I'll have a look and see if I can debug - no promises (kind of new to angular so...)

[mklkht]

Please fix this issue ASAP

[MvHMontySCOUT]

@mk-lviv @charlespockert @freeboarder

Hi, we had the same issue. I found some remarkable code 'issues' in the code beneath. No time to really dive into the library but I made a quick fix which is working for me in IE11 at least. I haven't tested every browser/version or different usage of ngDialog. So be aware for disappointments ;) I hope this can help you in fixing it for your case.

               performCloseDialog: function ($dialog, value) {
                    var id = $dialog.attr('id');

                    //MvH: seems to be undefined sometimes. why? cancel any action if so.
                    if (id == undefined) {
                        return false;
                    }

                    if (typeof $window.Hammer !== 'undefined') {
                        var hammerTime = scope.hammerTime;
                        hammerTime.off('tap', closeByDocumentHandler);
                        hammerTime.destroy && hammerTime.destroy();
                        delete scope.hammerTime;
                    } else {
                        $dialog.unbind('click');
                    }

                    if (dialogsCount === 1) {
                        $body.unbind('keydown');
                    }

                    if (!$dialog.hasClass("ngdialog-closing")) {
                        dialogsCount -= 1;
                    }

                    var previousFocus = $dialog.data('$ngDialogPreviousFocus');
                    if (previousFocus) {
                        previousFocus.focus();
                    }

                    $rootScope.$broadcast('ngDialog.closing', $dialog);
                    dialogsCount = dialogsCount < 0 ? 0 : dialogsCount;
                    if (animationEndSupport) {
                        scope.$destroy();

                        //MvH: undbind to bind an event? wtf? something is going wrong in IE11. Maybe triggered by the used CSS.
                        //issue: https://github.com/likeastore/ngDialog/issues/142
                        //quick(ugly)fix: remove entire DOM event after 
                        $dialog.addClass('ngdialog-closing');
                        setTimeout(function() {
                            $dialog.remove();
                            if (dialogsCount === 0) {
                                $body.removeClass('ngdialog-open');
                                privateMethods.resetBodyPadding();
                            }
                            $rootScope.$broadcast('ngDialog.closed', $dialog);
                        }, 500);

                        //$dialog.unbind(animationEndEvent).bind(animationEndEvent, function () {
                        //    $dialog.remove();
                        //    if (dialogsCount === 0) {
                        //        $body.removeClass('ngdialog-open');
                        //        privateMethods.resetBodyPadding();
                        //    }
                        //    $rootScope.$broadcast('ngDialog.closed', $dialog);
                        //}).addClass('ngdialog-closing');
                    } else {
                        scope.$destroy();
                        $dialog.remove();
                        if (dialogsCount === 0) {
                            $body.removeClass('ngdialog-open');
                            privateMethods.resetBodyPadding();
                        }
                        $rootScope.$broadcast('ngDialog.closed', $dialog);
                    }
                    if (defers[id]) {
                        defers[id].resolve({
                            id: id,
                            value: value,
                            $dialog: $dialog,
                            remainingDialogs: dialogsCount
                        });
                        delete defers[id];
                    }
                },

[richardszalay]

@MvHMontySCOUT unbind().bind() simply means unbind the previous events and then add a new binding.

The issue with your fix is that it assumes the animation speed is 500ms. A better "quick fix" would be to ensure that animationEndSupport is false for browsers known to act weirdly to it. It has the downside of not animating out for those browsers, but that's ultimately up to you whether that's preferable to the "flicker". I certainly wouldn't recommend merging the change that hard codes the animation speed.

Meanwhile, we can investigate what's causing the flicker. I'm guessing that the element is showing before the element is removed, even though both requests happen synchronously. Perhaps a hardcoded .css('display','none') (or opacity: 0) call before the remove?

[nkiriz]

@richardszalay How would you exactly apply animationEndSupport = false?

[MvHMontySCOUT]

@richardszalay: hmmm the context of the bind/unbind comment is lost due removal of the original code ;). the animationEndEvent event was removed and then directly added. I don't understand why that is necessary. the event is registered at line 27 and only used in the performCloseDialog.

Yes setting the animationEndSupport to false would be certainly better for a common prevention of the flicker but not as 'nice' as it is now. The animation duration is not a guess but determined from the CSS ;)

No PR from me. it is an ugly 'quick' fix which works for us now :)

[MvHMontySCOUT]

tried to use the css 'animation-fill-mode' to display the last fadeout keyframe containing opacity:0 and display: none with the original code but no success...

[richardszalay]

@MvHMontySCOUT I had the same experience. It does indeed look like an issue with the animationend event on IE. I've seen workarounds which parse the transition value and wait that amount of time, but that's a lot of effort and only cuts down on flickering 80-90% of the time.

Still, might be worth investigating at some point.

[MvHMontySCOUT]

@richardszalay I meassured the time it takes for IE to trigger the animationend event compared to other browsers. IE is 3x slower in triggering the animationend. (for me Chrome triggers in 5-7ms compared to 22-50ms in IE)

Though I have found a solution by using the 'animation-fill-mode' on multiple animations. few days ago I tried this also but I didn't applied it to the overlay. I'll create a PR today.

[kayz1]

Is this merged to master?

[faceleg]

Looks like it to me

[burjua]

Still can see flicker in IE11 both in 0.6.1 and 0.6.2 versions. Doesn't look like it's fixed.

[knulan]

flicker still happening in IE11. version 0.6.2