WinJS.UI.Animation.hidePanel method flickering the animated element at its original position after finishing


  • I have a panel that pops up from the bottom of the screen. The panel displays correctly, but when I go to hide it, using the WinJS.UI.Animation.hidePanel method, the element will often flicker onscreen in its original position for a split second before disappearing due to my repositioning it in the done statement of the animation promise. I have tried setting the element's visibility to "hidden," Its display to "none," and just moving the element down to its final position in the done method of the animation promise, all to no avail. If anyone knows anything about how to keep this flickering from occurring, I would like to hear it. The code for my animation method is below:

    animationPromise = WinJS.UI.Animation.hidePanel(panelElement, {
        top: "100%",
        left: "0px",
        rtlflip: false
    }).done(function () {
        panelElement.style.top = "100%";
        panelElement.style.bottom = "auto";
        animationPromise = null;

    Wednesday, December 19, 2012 9:45 PM


  • The best workaround I could find for this issue was using a call to WinJS.UI.executeTransition instead of the executeAnimation call that hidePanel uses. This keeps the transform property of the element's style set after the animation finishes. I am not actually certain why the in-built animations don't do this by default. Is there any compelling reason not to do this?:

    function panelTransition(element, startTrans, endTrans) {
        return WinJS.UI.executeTransition(element,
                property: "transform",
                delay: 0,
                duration: 550,
                timing: "cubic-bezier(0.1, 0.9, 0.2, 1)",
                from: startTrans,
                to: endTrans

    It would then be called with something like

    animationPromise = panelTransition(editRuleControls, "none", "translate(0px, 100%)").done(function () {
        animationPromise = null;

    Once again, is there any compelling reason not to do it this way? If not, I will just keep it.

    • Edited by GreenestBanana Thursday, December 20, 2012 2:50 PM Fixing name of method
    • Marked as answer by GreenestBanana Friday, December 21, 2012 3:45 PM
    Thursday, December 20, 2012 2:49 PM