may be a bug: about revertPop/go method in createHashHistory

[helios741]

Scenes

Recurring path

1. Jump from /user to /user/6.

• There is a button that can be rolled back in the /user/6 page.
• The block method is called in the /user/6 page.

2. Click the back button for /user/6.

• A confirmation box appears, because window.confirm()
• click cancel
• URL changes did not trigger UI changes

reason

go method

When the go function is triggered, it is not processed by transitionManager.confirmTransitionTo like triggering the push.

revertPop method

revertPop method

in line 151(if (toIndex === -1) toIndex = 0;) and line 155(if (fromIndex === -1) fromIndex = 0;) is not necessary.

If I think the problem is correct,I can give PR to history repo to solve this problem.

[DavOnGit]

I also noticed revertPop method of browserHistory.js sometimes fail to revert back!
I noticed that in one of this cases (after page refresh usually) var delta = 0 because allKeys.indexOf(toLocation.key) = 0 and allKeys.indexOf(fromLocation.key) = -1 that become 0 and so no-op happens, leaving the history out of sync!

@mjackson from createBrowserHistory.js, i can read this comment:

// TODO: We could probably make this more reliable by
// keeping a list of keys we've seen in sessionStorage.
// Instead, we just default to 0 for keys we don't know.

[mjackson]

Sorry about this. revertPop is a hack that can never actually work as intended. We are going to remove it in the next major release. I wrote more about it in #690.