History traversal

[johnbender]

We have an outstanding issue with the way the back button is handled. Of course, when hitting the back button we can't know where in the history stack we are so we to traverse it until we find the item in history that matches the new url. The way we do this now is just a linear run from the front of the history stack to the end and the last element that is found that matches the current url is picked as the location in the stack.

Example

root page --> page 1 --> page2 --> page 1--
                                          |
                        page2 <------------

The logic we have in place now will start at the root page in the history stack and search in the stack until it finds a url that matches (in this case page 2). This works great, but there is an obvious case were it falls down.

root page --> page 1 --> page 2 --> page 1--> page 2 --
                                                      |
                      page 2 <-- page 1 <--------------

In this case the second back button click, to page 2, will find the second page 2 and the history will think the forward button was clicked which is obviously wrong and causes the animation to be off.

Also keep in mind the history is trimmed whenever it diverges.

My thinking is that we should start at the stored index (our last known location) and traverse outward from there to find a matching url, starting with the backward direction (people hit the back button more than the forward button and there's no forward hardware button on phones). If nothing is found in the backward direction traverse forward to find the url.

The only corner case that this doesn't address is when there's an identical entry in both the backward and forward history, but this is a limitation of the platform

[johnbender]

Closed with the merge of the new nav