This is an issue that I stomped about 6 months ago, blogged about it, reported and got it confirmed by Microsoft, and just found out that after all this time, they didn’t fix it on Windows Phone 8!!
When the Windows Phone SDK started to allow developers to remove entries from the navigation back stack, they (inadvertly?) introduced a bug in PhoneApplicationFrame, more specifically in the CanGoBack property!
Here’s how to simulate the issue:
- Start by creating two separate pages
- On the application start page, add a Button that when clicked will just navigate to the second page (thus adding an item to the navigation stack)
- On the second page Loaded event, call the NavigationService.RemoveBackEntry (removing the previously added item from the navigation stack)
- Get the current PhoneApplicationFrame instance with
- Compare the NavigationService.CanGoBack and PhoneApplicationFrame.CanGoBack property values: the first indicates
false, the correct and expected value, while the second indicates
true, something that should not happen because we just cleared the navigation back stack when we removed the only entry that was there!!
By using a Reflection tool to look at the PhoneApplicationFrame implementation, one could easily realize that while the methods Navigate, GoBack, RemoveBackEntry and others are just proxies to the same ones on NavigationService, this is not true for the CanGoBack and CanGoForward properties, which have local values and only get updated after a navigation event!
And this is where lies the whole problem: the values of these properties should be obtained directly from NavigationService like the methods are, or at least they should also be updated when RemoveBackEntry method gets called!
You can test and confirm this bug by downloading this sample application.
All you need to do is run the app, click on “Navigate to self”, check that the stack count is now 1, click on one of the two buttons for the “RemoveBackEntry” and realize that the CanGoBack properties now have different values!
This situation has been fixed in the implementation of the INavigationService on Cimbalino Windows Phone Toolkit, but be aware that there are still a lot of similar services implementations from other toolkits and frameworks that have this bug…
Updated on 20/01/2013: After a few tweets with Joost van Schaik, he updated the INavigationService implementation on Wp7nl utilities to match the Cimbalino Windows Phone Toolkit.