Ticket #13 (accepted bug)
Find a solution to the "repetition of history" problem for manually re-entered hashes.
| Reported by: | nathanhammond | Owned by: | nathanhammond |
|---|---|---|---|
| Priority: | major | Milestone: | Version 1.0 |
| Component: | JSSM Object | Version: | 0.9 |
| Keywords: | Cc: | ||
| Blocking: | Blocked By: |
Description
There is a possible fail state if a person manually re-enters a previously existing hash: it will be appended to the end of the history, but the stack pointer will be adjusted to the first time it appeared in the history stack. This creates a state where you've come to the page "fresh" but are loading in the old state.
PARTIAL SOLUTION: Watch for changes in window.history.length. Compare these to the initial length when arriving at the page and the number of items on the site's stack.
Success Scenarios:
1. A manually re-entered hash that matches the current one won't trigger an event or change the length (click location bar, press enter, no change).
2. A manually re-entered hash that doesn't match the current hash changes window.history.length, and is catchable.
Fail Scenarios:
1. The user is exactly one spot deep in the browser history stack. The length does not change because it pops all future events off the stack and adds a new one immediately.
![(please configure the [header_logo] section in trac.ini)](/jssm/chrome/site/your_project_logo.png)