Bug in the PhoneApplicationFrame.CanGoBack RRS feed

  • General discussion

  • Yesterday I manage to find a bug in the PhoneApplicationFrame, regarding the RemoveBackEntry() method and the CanGoBack property!

    Here's how to simulate the bug:
    • Start by creating two pages
    • On the start page of the application, add a button that when clicked will start navigating to the second page (thus putting an item in the navigation stack)
    • When the second page loaded event, call the NavigationService.RemoveBackEntry() method (thus removing the item previously added item from the navigation stack)
    • On the same event handler, get the current PhoneApplicationFrame instance with this code: var frame = (PhoneApplicationFrame)App.Current.RootVisual;
    • Now compare the values from NavigationService.CanGoBack and frame.CanGoBack properties: the first indicates false, the correct and expected value, while the second indicates true, something that should not be correct because we have just cleared the navigation stack by removing the only navigation entry that existed there!

    Using a reflection tool to see the code from PhoneApplicationFrame, I could easily perceive that, while the methods Navigate(), GoBack(), RemoveBackEntry() and others call the same method from NavigationService, the same does not happen with the properties and CanGoBack and CanGoForward: these two properties are cached in the PhoneApplicationFrame and only updated after a Navigation event occurs (but not when the RemoveBackEntry is called!)

    I posted a complete sample code as proof for this issue, you can find it here (the post is in Portuguese, but Microsoft Translator is on the bottom of the page).

    If someone else could download the code and confirm my findings I'd be much appreciated!!

    Friday, June 22, 2012 4:21 PM

All replies

  • I am able to reproduce the problem...

    Is there a scenario where you would need to use PhoneApplicationFrame rather than NavigationService?
    Friday, June 22, 2012 6:33 PM
  • First thing, thank you for confirming it! :)

    Actually, this is a bug that affects almost everyone using MVVMLight and made a specific service for navigation using this sample from Laurent Bugnion (MVVMLight author)

    That particular sample has been the base for numerous implementations for an INavigationService and you can find it on Wp7nl utilitiesthis article from WindowsPhoneGeek, my personal implementation on the Cimbalino Windows Phone Toolkit, and probably many others... granted, my personal implementation is the only one that might expose the issue because I was the only one that implemented a RemoveBackEntry method - yet, the method exists in the 7.1 SDK and I do think it should be available to use!

    As you can see, what they all have in common is the usage of the PhoneApplicationFrame methods for navigation control, so all of them can come to this issue.

    The NavigationService exposed on the PhoneApplicationPage is the same instance that the PhoneApplicationFrame uses, but the frame class declared it as internal, so there is no way we can use it... and in an pure MVVM environment, we never access the Page object!!! ;)
    Friday, June 22, 2012 10:14 PM