I'm currently implementing a JavaScript library that keeps track of the history of changes to the hash part in the address bar. The idea is that you can keep a state in the hash part, and then use the back button to go back to the previous state.
In most of the recent browsers, this is automatic and you only have to poll the location.hash property for changes (In IE8 you don't even have to do that; you simply attach a function to the onhashchange event.)
What I'm wondering is, what different methods are there to keep track of the history? I've implemented functionality that has been tested to work in Internet Explorer 6/7/8, Firefox and Chrome, but what about other browsers? Here's the ways I currently keep the history:
Edit: See my answer below instead for a walk-through of the various browsers.
First of all, thanks to you guys who answered! =)
I've now done a lot more research and I believe I'm satisfied with my implementation. Here are the results of my research.
First of all, my finished Hash library. It's a stand-alone library with no dependencies. It has two functions: Hash.init(callback, iframe) and Hash.go(newHash). The callback function is called whenever the hash changes with the new hash as its first argument, and as its second argument a flag indicating whether the callback is called due to initial state (true) or an actual change to the hash (false).
Hash.js (MIT license)
I also made a jQuery plugin for making it easier to use. Adds a global hashchange event as well. See example in source code for how to use it.
jquery.hash.js (MIT license)
To see them in use, go to my JavaScript "realm" page:
Blixt's JavaScript realm
Internet Explorer 8
Smooooth cruisin'! Just smack on one o' them onhashchange events to the window object (using attachEvent) and get the location.hash value in the event handler.
It doesn't matter if the user clicks a link with a hash, or if you set the hash programmatically; history is kept perfectly.
Chrome, Firefox, Safari 3+, Opera 8+
Smooth cruisin'! Just poll for changes to the location.hash property using setInterval and a function.
History works perfectly. For Opera, I set history.navigationMode to 'compatible'. To be honest, I'm not sure what it does, I did it on recommendation from a comment in the YUI code.
Note: Opera needs some additional testing, but it has worked fine for me so far.
Surprise quirk bonus! (Can it be?!) It turns out that Firefox (only confirmed in 3.5+) decodes the location.hash property, so this can trigger a hashchange event twice (first for the encoded version then for the unencoded version.) There is a new version of my Hash.js library that takes this into account by using the location.href property instead (changes provided by Aaron Ogle.)
Internet Explorer 6, 7
Now it gets nastier. The navigation history in older Internet Explorer versions ignore hash changes. To work around this, the commonly accepted solution is to create an iframe and set its content to the new hash. This creates a new entry in the navigation history. When the user goes back, this changes the content of the iframe to its previous content. By detecting the change of content, you can get it and set it as the active hash.
Checking for changes to the location.hash property is still needed to manual changes to the current address. Beware of the quirks I've mentioned below, though.
While this solution seems to be the best one out there, it's still not perfect in Internet Explorer 6, which is a bit quirky about the back/forward buttons. Internet Explorer 7 works fine, though.
Surprise quirk bonus #1! In Internet Explorer 6, whenever there's a question mark in the hash, this gets extracted and put in the location.search property! It is removed from the location.hash property. If there is a real query string, however, location.search will contain that one instead, and you'll only be able to get the whole true hash by parsing the location.href property.
Surprise quirk bonus #2! If the location.search property is set, any subsequent # characters will be removed from the location.href (and location.hash) property. In Internet Explorer 6 this means that whenever there's a question mark in the path or the hash, you'll experience this quirk. In Internet Explorer 7, this quirk only occurs when there's a question mark in the path. Don't you just love the consistency in Internet Explorer?
Surprise quirk bonus #3! If another element on the page has the same id as the value of a hash, that hash will totally mess up the history. So rule of thumb is to avoid hashes with the same id as any elements on the page. If the hashes are generated dynamically and may collide with ids, consider using a prefix/suffix.
Other browsers
Unless you've got an out-of-the-ordinary user base, you won't need to support more browsers. The browsers not listed above are in the <1% usage category.
Based on the effort that you've put into this, I would assume that you've seen YUI Browser History Manager, but just in case ...
They give a nice write up of their implementation, and I find their source code very readable.
Here's what it says about Opera
* location.hash is a bit buggy on Opera. I have seen instances where
* navigating the history using the back/forward buttons, and hence
* changing the URL, would not change location.hash. That's ok, the
* implementation of an equivalent is trivial ... more below
Searching the source I found some accomodations for Safari 1.x & 2.0 also. Seems like you'd be interested in it.
Hope that helps.
I am not sure I fully understand your needs, but I have used the Really Simple History library (http://code.google.com/p/reallysimplehistory/) for implementing something similar. You can see it here: http://whiteoak.sourceforge.net/
I haven't seen anything mentioned about what I am about to say anywhere so I thought I'd share and see how common knowledge it is.
In IE (only verified in IE7), the history with the hash works correctly when there is a page element on the screen with an id equal to the hash. For example, think of a table of contents (TOC) on a wiki page. Each link in the TOC links to a hash of an id or anchor name element somewhere on the page:
<div id="TOC">
<a id="SampleHeaderLink" href="#SampleHeader">Sample Header</a>
</div>
<h2 id="SampleHeader">Sample Header</a>
So when SampleHeaderLink is clicked, the IE browser default setting is to navigate to SampleHeader and register the state in the history. Using the back button and forward button works as expected.
However, if the SampleHeader div does not exist on the page, the browser only registers the url changing but does not create a new state for it.
Again, this is only verified in IE7. And I don't know how common-knowledge this information is but I never found anything related when I was browsing to fix this very issue in my own application.
GWT provides history management. It is also an integral part of their MVP framework. They have also enhanced the history API with places and activities.
Related
For non-negotiable reasons unique to the legacy system I am doing work on, a POST query is used to switch between tabs of a particular web interface.
On occasion, I need to trigger a refresh of the current tab and would typically use js's location.reload() to accomplish this. However, in this context the behavior is different in Firefox vs. Chrome.
Specifically, FF resubmits the POST query that brought me to my current page, whereas Chrome does not. As a result, FF ends up where I started, and Chrome instead goes to the URL in the address bar.
Does anyone know of a cross-browser means of accomplishing what FF does by default on location.reload()?
Try using it with true
window.location.reload(true);
I believe this is a bug in Chrome.
Take a look at the attached bug description.
http://code.google.com/p/chromium/issues/detail?id=30479
Although it mentions the back button, I see the same issue using location.reload(true) if I have a form using session cookies. That is, in IE and FF it reposts and reloads OK. In Chrome it does not.
Reload using location property:
window.location = window.location;
I have a horrible, scattered page with lots of JavaScript:
It has a list view and if you like you can watch one of the items in the list in detail.
The problem is now if I want to go back from the details view to the list view by using the browser back button I get different results.
In Chrome and Firefox, even in IE7 I will end up where I clicked, but not so in IE8.
To make it even more confusing, if I switch JavaScript off it works for IE8 as well.
The problem is now I don't now where to search. Does somebody know this problem or at least a JavaScript method or function which could affect this?
It is difficult to provide a definitive answer without the code. A tentative answer based on past experiences with IE:
IEs have different behaviors, especially IE8 which is at the crossing of the old and all but standard versions [IE6-, IE7] and the newer IE9 that better sticks to standards. In particular in Javascript, IEs may be picky compared to non-IE browsers.
That back behavior could happen if a JS error is triggered either when you leave the page (thanks to the link click), or when you come back (which is easier to spot)
Check if an error occurs when leaving (or coming back) at the bottom of the page
The click action could be delayed thanks to setTimeout which function would set window.location.href to give you enough time to spot an error before the page is left
If the redirect is "manual" (like window.location.href= as opposed to a simple <a> tag) Try to add a try {} catch around the code that run after the element is clicked (like with this onbeforeunload bug).
I have a single-page mobile application developed with Backbone and Zepto.
It works correctly with the back/forward buttons in the browser.
When the user navigates to a page, the new content slides in from the right as the old contents slides away to the left (and out of the viewport). I want the same thing to happen if the user presses the "forward" browser button. This all works.
I've got a class that I add to the body element navigate-back that will flip this behaviour, so when the user navigates back with the browser's back button, they see the content sliding back in from the left and the other content sliding into the right. Basically just the opposite of going forward.
I need to detect if the user is navigating backwards so I can invoke the alternate behaviour. I have tried implementing my own history stack, but I've ran into lots of problems where sometimes it marks a forward as a back navigation which ruins the visual cue. It's descended into a kludge of hacks now and probably would only embarrass me if I posted it.
What is the best way to implement my own history stack so I can detect if the user is navigating forward/back in the context of a single-page Backbone mobile application?
I don't know about backbone.js1, but I have helped develop a mobile application which had to implement exactly this behavior in html5, so I should be able go give some good advice:
First of all it's good to know that the history.pushState function exists. The big problem with it though is that it is supported up to android 2.3, but not on android 3 till android 4.0.3. As kiranvj points out correctly this can be solved by using the popular history.js library which provides a polyfill solution for the lack of the history functionality.
Now, getting to your actual problem, the way I implemented the history direction animations was by adding data to the pushState function ( history.pushState(data,title,url) ) with which I identified the logical position of the page. In my application I wasn't only limited to a horizontal bar, but in your case you would keep track of position where any new loaded page get's a position which is one higher then your current page. E.g.
History.pushState({position:History.getState().data.position+1},"Your title","Your URL");
Next, when the window.onstatechange or window.onanchorchange event triggers you observe whether the position is higher or lower than your current page (e.g. by using the history.js History.getState() function which I used above) and depending on this you decide in which direction to move (lower is to the left, and higher is to the right), as is illustrated by the image below:
You will also note that I already assumed on the first page that you have {position:1}, whereas normally the first page will have no state information. The way this can be achieved is by using history.replaceState which replaces the current empty state with a more informative state. Alternatively you can also check for an empty state on any of the previously mentioned events and if it's empty you assume it to be the left most one ({position:1}).
Hope this helps and if you have any additional questions feel free to ask.
Please note that this answer assumes you are using history.js and you would need to listen to slightly different events (such as onpopstate) and use slightly different structures (history rather than History) if you would want to build your own solution.
It is also useful to note that it is possible to build this with your own queue array which gives you a lot more control, but will not work in combination with the browser's back button. This is a big issue with browser sites, however is far easier in case you are building a cordova (a.k.a. phonegap) web application.
1 Just read about it and it appears to do some history handling of its own, which might make it more complex to integrate the technique described above.
If you're working on a true single-page app, why not you set up an array to hold history urls in a js variable (as opposed to relying on something like history.pushState and its support)?
Whenever a new page is navigated to, you can push its url into the array, whenever a "back" button is pressed, you can retrieve the url needed as far back as you want. This will work perfectly as long as you correctly discard urls when the user goes back a few steps and then navigates to a new link.
I've never tried implementing this to be used for page history, but this worked perfectly well for in-page undo-redo logic.
Update:
After further research, the approach above would not work for a page reload as it would be an action occuring outside of history handling available through JS. It would still work for tracking back/forward transitions, but such history will be lost on navigating to a url external to the app or a page refresh. David Mulder's answer seems to lack this limitation by relying on browser-level history that persists outside of the page scope.
I had the same issue when working with Zepto on mobile with single page - multiple views.
Initially I used html5 statechange and onhashchange. It all have some issues in one or other mobile device. Finally I used Zepto history plugin from here https://github.com/browserstate/history.js
It somewhat solved most of the issues. Try it, it will be useful, it handle html4 and html5 features wherever possible.
Use this thing in single page mobile application this will allow to the history and move the user to back.
function onBackKeyDown() {
history.go(-1);
navigator.app.backHistory();
}
Sammy.js's v.6.x branch (the one that relies just on hash changes) is a perfect, simplest, most browser-compatible approach to tracking history. There, history is not tracked at all, as Sammy just watches for hashchange.
Relying on "#/slide/123" allows you to support hard page reloads, and simplifies the work
Peel off the last part (slide number) on each page view, push into global. On new route, see if number is more or less than what is stored in global and do the correct (left or right) animation. If global is undefined, no animation.
I change the bookmark in the url when the page is loaded. That way, when the user clicks the back button of the browser, the browser will not actually go back, but will instead change the bookmark. I can then detect the bookmark change and do something else as a reaction to the user pressing the back button.
My problem is to find the current url, including any bookmark/hash changes. It works in all browsers, using a combination of the following, but not in IE8:
document.URL
location.href
window.location.hash
and the window.onhashchange
As it doesn't work for IE8, could anyone possibly point me in the right direction towards how I can detect the bookmark/hash change in IE8?
Look at jquery-bbq, as it implements the hashchange and makes it work in IE6-IE8 and possibly IE9 now. You could probably entirely rely on it instead of your custom code.
According to the author of the jQuery hashchange plugin, IE8 supports binding to the window.onhashchange event out of the box.
Perhaps you could try using Ben's plugin, which is intended to enable hash change detection on older browsers.
EDIT: My tests showed that the event is not firing in IE8. Then I found the following comment in above plugin's source code:
// Note that IE8 running in
// IE7 compatibility mode reports true for 'onhashchange' in window, even
// though the event isn't supported, so also test document.documentMode.
Apparently, I'm running in documentMode 5 which is quirks mode. I bet it works in IE8 standards mode only. Regardless, you should be able to implement the same JS code that Ben used.
As is well known, in XHR (aka AJAX) web applications no history for your app is build and clicking the refresh button often moves the user out of his/her current activity. I stumbled upon location.hash (e.g. http://anywhere/index.html#somehashvalue) to circumvent the refresh problem (use location.hash to inform your app of it's current state and use a page load handler to reset that state). It's really nice and simple.
This brought me to thinking about using location.hash to track the history of my app. I don't want to use existing libraries, because they use iframes etc. So here's my nickel and dime: when the application page loads I start this:
setInterval(
function(){
if (location.hash !== appCache.currentHash) {
appCache.currentHash = location.hash;
appCache.history.push(location.hash);
/* ... [load state using the hash value] ... */
return true;
}
return false;
}, 250
);
(appCache is a predefined object containing application variables) The idea is to trigger every action in the application from the hash value. In decent browsers a hash value change adds an entry to the history, in IE (<= 7) it doesn't. In all browsers, navigating back or forward to a page with another hash value doesn't trigger a page refresh. That's where the intervalled function takes over. With the function everytime the hash value change is detected (programmatically, or by clicking back or forward) the app can take appropriate action. The application can keep track of it's own history and I should be able to present history buttons in the application (especially for IE users).
As far as I can tell this works cross browser and there's no cost in terms of memory or processor resources. So my question is: would this be a viable solution to manage the history in XHR-apps? What are the pros and cons?
Update: because I use my homebrew framework, I didn't want to use one of the existing frameworks. To be able to use location.hash in IE and having it in it's history too, I created a simple script (yes, it's needs an iframe) which may be of use to you. I published it on my site, feel free to use/modify/critizise it.
There are 3 issues that tend to get munged together by most solutions:
back button
bookmarkability
refresh button
The window.location.hash based solutions can solve all three for most cases: the value in the hash maps to a state of the application/webpage, so a user can press one of "back"/"forward"/"refresh" and jump to the state now in the hash. They can also bookmark because the value in the address bar has changed. (Note that a hidden iframe is needed for IE related to the hash not affecting the browser's history).
I just wanted to note however that an iframe only solution can be used without monitoring window.location.hash for a very effective solution too.
Google maps is a great example of this. The state captured for each user action is way too large to be placed into window.location.hash (map centroid, search results, satellite vs map view, info windows, etc). So they save state into a form embedded in a hidden iframe. Incidentally this solves the [soft] "refresh" issue too. They solve bookmarkability separately via a "Link to this page" button.
I just thought it's worthing knowing/separating the problem domains you are thinking about.
I think you'll have a tricky time knowing if a user went forward or back.
Say the url starts /myapp#page1 so you start tracking states.
Then the user does something to make the url /myapp#page2
Then the user does something to make the url /myapp#page1 again. Now their history is ambiguous and you won't know what to remove or not.
The history frameworks use iframes to get around the browser inconsistencies you mentioned. You only need to use iframes in the browsers that need them.
Another con is that users will always go for their browsers back button before they will go for your custom back button. I have a feeling the delay on reading the history every 250ms will be noticeable too. Maybe you can do the interval even tighter, but then I don't know if that'll make things perform badly.
I've used yui's history manager, and although it doesn't work perfectly all the time in all browsers (especially ie6), it's been used by a lot of users and developers. The pattern they use is pretty flexible too.
All that stuff is important for supporting the full range of browsers, but hopefully the need for it will go away. IE8 and FF3.6 both introduced support for onhashchange. I imagine that others will follow suit. It would be a good idea to check for the availability of this functionality before using timeouts or iframes, as it is really the nicest solution currently out there - and it even works in IE!