Reloading a page in WinJS fails to attach event handlers

Question

I have a WinJS application (a Windows 8.1 app using HTML/JS, not C#/XAML).

I've implemented a custom navbar in my default.html, with some buttons that have click event listeners attached to them. Each handler calls nav.navigate() with the url of the page corresponding to the nav button.

One of my pages (call it /pages/myPage/myPage.html) has several buttons on it. Each button has a click event listener bound to it in the page's ready function. This works fine when navigating between several pages.

However, if I'm on myPage (with working button click handlers) and click the navbar button for myPage again, the page looks like it reloads. The ready function seems to be called (i.e. it console.log statements in it are executed), but the buttons on the page seem to completely lose their click handlers!

If I navigate to another page, then navigate back, the buttons work fine again. But no matter what I do, "reloading" the page by navigating to itself (nav.navigate("/pages/myPage/myPage.html") while on myPage) causes my click handlers to be lost.

Why does this happen? My ready function is called, but somehow the click handlers are never re-attached.

Here's what the ready function for myPage looks like:

    ready: function (element, options) {
        document.getElementById("myButton").addEventListener("click", this.myButtonClicked);
    },

Here's what the click event listener for the myPage nav button looks like (this code is in default.js):

    myPageNavButton.addEventListener("click", function () {
        nav.navigate('/pages/myPage/myPage.html');        
    });

Answer 1

Page nav in WinJS is just a matter of DOM replacement. When you do a nav, the target “page” contents are loaded into the DOM and then the previous “page’s” contents are unloaded. You can see this in navigator.js in the _navigating method. It creates a new element for the page being loaded, renders that fragment therein, and then unloads the old page.

The ready method for the new page, however, is called before the old page is unloaded (this was a change in WinJS 2.0, as WinJS 1.0 unloaded the old page before calling ready). The upshot of this is that when you navigate to the same page that’s already loaded, myPage.html(A) is in the DOM when you load myPage.html(B). When you execute the code in your ready method, then, getElementById will find the buttons in myPage.html(A) and so you're attaching handlers to that element. But then after you return from ready, myPage.html(A) is unloaded, so you lose the handlers. And because you never attached handlers to the buttons in myPage.html(B), they're just inert.

So what can you do about it? The best solution, in my mind, is to avoid navigating to the same page in the first place, because it's just fraught with other peril in the long run. To do this, wrap your call to nav.navigate with a check for whether you're already on the target page. Here's an implementation of a function that does that:

function navigateIfDifferent(target) {
    var page = document.getElementById("contenthost").winControl.pageControl;
    var fullTarget = "ms-appx://" + Windows.ApplicationModel.Package.current.id.name + target;
    if (fullTarget !== page.uri) {
        WinJS.Navigation.navigate(target);
    }
}

This assumes that the PageControlNavigator control that you're using is in a div called "contenthost" in default.html (which is what the VS template gives you). What I'm then doing is building the full in-package URI for the target page and comparing that to the uri of the current page control, which is also a full in-package URI. You could also strip off the ms-appx:// part from the current page URI and compare to the target URI. Either way.

Anyway, with this function, replace your calls to nav.navigate with navigateIfDifferent, and you should be good.