This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
This is a suggestion to fix major problems relating to developing a more modern application as related to browser history issues. The recommendation is to allow the history command to return both an array and current index. Cur Spec Ref: http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#the-history-interface I speculate these key things are missing for security reasons as we don't want a developer to see a users entire history (beyond their domain). With the security concern in mind. I think that it would be fine to return only the history subset for a given domain, [and also as an extra thought be maybe be able to ask for it within the context of a url or path within that (a subset).] To further clarify. When my JavaScript in my domain www.mysite.top has been reached via a search engine like google there is a history before the point of getting to my site that is securely protected and not available (that's great and important to maintain). [Possible syntax jist] One would ask for the "Current Domain's History" somehow this would be an array of objects with "title" and "url" and "state" key/value pairs. As well you could ask for the current index within that maybe history.currentIndex("site") Maybe a 'domainHistory' object instead of the useless 'history', but the spec is also still missing a way to access the current index (for that proportional history's array). Currently you can get the length of the history and looking at the history doesn't tell you anything. It's featureless and disabled and unusable (again it seems limited for security reasons, which is solvable and not necessary by domain separation.) The 'State' system is an interesting solution (and obviously useful and should still be usable in the same way) but if I can't inspect the state of a point back in history I can't 'go' there to inspect it and still be running my page's code. The state system is basically useless if I can look at my history as I can save state elsewhere anyway. Basically here is a modern development paradigm example and how the existing system fails us. Now days (and definitely in the future) all pages of a site are smoothly transitioned via divs as dynamic content and no longer does the page actually change in the conventional sense. One is using hashTags (and possible State) to help with history navigation. Now if you have a sequence of pages with a complex branching hierarchy maybe the user enters a url manually and we are really needing to go back in the history to where that page branches and loading maybe another page further up a different branch before getting to the page. I can simulate that as is, but when someone does a refresh etc. it's going to break without being able to get back to page 1 in your domain's history. It's basically impossible to build a site with branch aware history when it's history is concealed from the developer. Doing otherwise will ultimately be confusing and brake things. We need to go back to a branching point and load there while not leaving an added (manually) page request at the top of the history stack. The best solution I can see is to give access to the history of at least the current unbroken chain of the same domain that the developer is working on/in/from. This is not a security concern, and too disabling for a modern app not to be accessible. I've tried methods like trying to step back through the history but eventually when you find the beginning your code is no longer running. There are also situations where I want to delete the history forward (to remove the manual page request that is for a page that is actually back in the history tree/branch) and have had to hack it so when you clear forward the history it loads a page with that detectable hashTag and then goes back one in history (as you may opt or need to remove all the history forward from the branch point you've come back to [or possibly mark them as outdated and in need of refresh on load etc.). You should be able to manipulate the history like any array, add, delete and replace items with one or more chains of history items as needed and not be locked out of the most fundamental primary concept of site navigation as is the current state. If anyone reading this could please take the time to escalate it and repost this somewhere more appropriate the world would benefit greatly. At least discuss with some peers the madness of the current inaccessibility of the browser window history. For me it seems this is the most important and major problem moving forward with HTML5 and Web "2point-oh" $H!#. Of course it is a problem because we're locked out of it, but it's the most fundamental first step to anything navigation.
Looks like this was meant for the HTML spec.
Can you elaborate on what you mean by "branch-aware history"? I'm not sure I understand what this would look like to the user. Can you describe a concrete user experience that you can't implement today?
Yes thanks for asking and following up. Basically today if you type a url (or however [maybe a list of emailed link] as an extreme example for instance) at the 'top' [aka the URL entry textfield] that has been visited the client browser simply appends another duplicate instance (being the next page visited), but if in the middle of a complex history path, actually further ahead of that page in the logic flow it would be critical to revert back in the history to the correct location. Here is an example of my paging system's sequence xml file (hopefully I don't have to edit this to insert.... <sequences> <seq name="default"> <page name="Intro"> <page name="Start"> <page name="V1P1"> <path route="alternating" path="V1P2/V2P1/V2P2/V3P1" join="results" /> <path route="OneAtATime" path="V2P1/V3P1/V1P2/V2P2" join="results" /> </page> </page> <page name="More"> <page name="About" /> <page name="Contact" /> <page name="Credits" /> <page name="Share" /> </page> </page> <page name="results"> <path path="V3P2/Scores/Video" /> </page> </seq> </sequences> now the path of logical history or aka branch-awareness is capable of defining a branch that splits into two ways of page routing from Players alternating through setting values (and then converges branches to match with the flow of showing the results). Some Value1 for Player1 V1P1 then player 2 V1P2 and another value V2P1 V2P2 and so on alternating or you might do all the values for player1 and then all the values for player 2 so that would be [OneAtATime]... Val1 Player 1 (or V1P1) and then Val2 Player 1 (or V2P1) and then the other player V1P2 & V2P2, etc. through values N. it then converges or joins branches back to the results sequence of pages. Anyway this is just my case example to help understand it could be anything. The reality is that the history should be customizable to go back to the page in question in the history and that there be only one page of a type in the history at a time because they are in logic sequence (not the typical visited sequence). To do otherwise will cause problems trust me on this (being a simple toy example here potentially). Yes one can also imagine that you could allow looping or a loopCount etc. and yes this is mostly handled on my/our aka the developers end... BUT it will break if the developer can not see better what the history in the browser is for that site/domain/session. Okay so when does all attempts to make it work with A 'disabled' (and hidden from developer's code) 'history' cause serious problems. If they reload the responsive jQuery type interface (page with hash-tags for history tracking), it will reload the code, at that point with all the settings wiped out so you can't tell how far back in the history to go (as I'm currently forced to keep track of that separately but alas it's refreshed) without seeing the history (at least for the domain). If I could see how far back the session goes I could go back to the start and delete the history beforehand otherwise if they jump back, different values etc. can resurface and cause major problems. So yes a history my also jump to two steps down a different branch that split a few pages back. You need to go back deleting however many pages and then insert the missing pages into the history maybe without visiting them, and finally end up on the correct page. Otherwise going backwards would jump you off the history again and not really go back to where when your on that back the back arrow should take them (which is not realistically in a modern app suppose to be where they just were, the old way falls short.) Anyway so some may want or need to do this type of page navigation in the future. I can propose at least one example of how this could work to maintain security without disabling the developer (of which I'm sure you could find others maybe more suited). Basically lets assume the developer needs to and should be able to ask for the history within their domain, see and inspect if their are pages for before or pages ahead that match the load request or don't and jump to them or back to clear the history. If the session added a history-validation state cookie or something that would be enough to securely say, "yes I'm authorized to see all the history entries that match that history state cookie/marker". Maybe you want to keep that restricted to contiguous blocks then fine. Reflecting: I can imagine how further back in browser design history a decision was made to protect the history of the user from other sites looking into what they've done, and that makes sense and should maintain, but to disable the fresh reloaded url or other url from an external link for instance with it's reloaded javascript, from seeing that sites own history is not only now days an over-site but verging on insanity, for whatever reason the developer wishes (of that site/app wishes. Also they were not responsive or intelligent and then it was okay but this is a major mistake now and easily fixable. Please let us see our sites history but keep the browser complete history hidden as that does make sense. Added thoughts: if I ask the history to step back one page at a time (trying to find the beginning) eventually it breaks because the page before that isn't from the session's site and will not contain the code running anymore so attempts to go back result in leaving the site (very bad). Attempts to wipeout the history ahead from a reloaded first page that destroys the session's stored states and values (ultimately my manual tracking of the history state), is currently not possible. However I am able to load a page called #clearHistory and when the javascript sees that it jumps back to the previous page so essentially removing the history ahead. This is a really bad hack too, but is the only option available without being able to manipulate the history pages ahead or other then the current, (or at least clear the history ahead), but again as explained before one also needs to add and insert pages into the history without necessarily going there to maintain a logically history or as I originally coined it branch-aware history. Let me know if you need anymore explanation that hiding my domain/site/history is bad, and therefore please take a minute to explain otherwise how hiding it is good and needed or necessary and not partially disabling in our now new modern development environment of JavaScript and HTML5 Application landscape. So yes please just add a way to validate the pages that are shared (via the developer setting a state visualizing authentication cookie maybe) and allowed to be exposed by a new history function. This really should expose the url and the history state objects as well as page titles I imagined. This would also show the length of the array of their rightfully observed now newly visible and fully editable history. Thanks for listening and doing your part in making the web spec a better place for everyone.
I don't understand what you are saying, sorry.
Gotta, could you briefly give a concrete example (like, "On YouTube, if you click this, then this, then this...") that shows what you mean? I'm having trouble understanding your bug report.