When you access a url that has several anchor tags on it. You know what I mean, links at the top that navigate to a specific point in that page by adding a "#name" at the end of the url. In every other browser, if you click on a few of them and then start clicking the back button the browser will recognize the change in url and navigate to that specific point in the page. But in ie7, if you click a few anchor tags on the same page and then start hitting the back button, you will notice that the browser floats to the top of the page each time you hit back. This is because ie does not update the "location" object if you are navigating backwards through hashes. I am looking for a fairly simple way of pulling the hash from the url in the instance that you are using ie7 and hitting the back button through hashes on the same page.

Does this make sense. I could use the realsimplehistory library but that just seems like way too much overhead for such a simple functionality for one browser version.

Got everyone stumped huh? Ya, me too.

here is a url to an example of what I am talking about.

http://test.ositnet.com/

You will see that in ff, ie8, chrome and probably any other browser besides ie7, the location object get updated. But in ie7, if you click a few of the links, which just add hashes to the url, the location object stays exactly the same as you hit the back button and reiterate back through the history.

OS_dev,

You can't change the browser's native behaviour but you may be able to write your links to force location="...." as opposed to the behaviour you are seeing in IE7.

For example:

<a href="#SectionA" onclick="location=this.href; return false;">Section A</a>

I haven't got IE7 available at the moment so I can't test. It certainly works in IE6 and FF 3.5.8

May work in IE7 may not, give it a try.

Airshow

OS_dev,

You can't change the browser's native behaviour but you may be able to write your links to force location="...." as opposed to the behaviour you are seeing in IE7.

For example:

<a href="#SectionA" onclick="location=this.href; return false;">Section A</a>

I haven't got IE7 available at the moment so I can't test. It certainly works in IE6 and FF 3.5.8

May work in IE7 may not, give it a try.

Airshow

Thankyou for your reply.

Ya, I can force it but what I am trying to do is sense back button actions. Lets say you have an ajax app where you are navigating through history which is defined by hashes. You need to be able to determine if the hash has changed in order to perform the correct related action. Every other browser updates the location object in this case accept ie7. I would be happy to force the location object to update, but if I could do that then I wouldn't need to because I would already be aware of what the current hash is.

Arrrrgggg! this is so lame. So many users still use IE7 and it is a piece of #$%^.

Anyway, I think I got it as good as I am going to get it. The only option that I have seen is using the realsimplehistory library, which is still buggy in ie7, but hopefully I can get it to do what I want it to do.

Ya, I can force it but what I am trying to do is sense back button actions. Lets say you have an ajax app where you are navigating through history which is defined by hashes. You need to be able to determine if the hash has changed in order to perform the correct related action. Every other browser updates the location object in this case accept ie7.

The thing of interest here is not so much window.location but window.history , which has properties .current , .length , .next , and .previous ; and methods .back() , .forward() , and .go() .

The properties are probably not much use as they are private (only available to signed scripts). The methods may be of greater interest.

The history object is actually Javascript's representation of an underlying browser object, hence history.back() and history.forward() , do exactly the same as the browser's back and forward buttons. history.go() simply allows you to go back/forward more than one location in a single leap. Therefore, with regard to going back/forward, you can do no more with Javascript than you can with the browser itself.

However, what you can do with Javascript is to control what goes into the history object. For example, by using the location.replace() method (rather than location= or location.href= ), the new location replaces the last location in the history object, rather than being appended to the stack. This is the behaviour you are trying to avoid, which is why I suggested trying location= .

I would be happy to force the location object to update, ....

If the new hash is obeyed (ie. window scrolls to put the corresponding named anchor in view), then window.location must also be getting updated (and I guess it appears in the browser's address bar). It would appear that IE7 fails to append the new hash to its history object hence the difference in behaviour between IE7 and other browsers.

.... but if I could do that then I wouldn't need to because I would already be aware of what the current hash is.

This seems to be a different scenario from the one painted in your original post. If I can understand how your sequential hash strings are generated/orchestrated, then I may be able to shed more light.

Airshow

All of the things that you mentioned have to do with modifying the location object or navigating or replacing browsing history. This is not what I want to do.

When you have an ajax app, it is standard to manage the history of your ajax app through url hashes rather than url changes. For example: on any normal site you can cleanly navigate through the history because each action has a distinct browser refresh and url. But in an ajax app you update the hash and connect that hash with a specific ajax event so that when the user hits the back button several times, each hash triggers the assigned ajax event as the user goes back in history.

In order to do this, the browser needs to be able to recognize when the hash was changed. Not a forward change but a backward or history hash change.

for example, if I go to joeblow.com which is an ajax app, not really but lets pretend. I click on say, about us. rather than the browser being redirected to joeblow.com/aboutus instead what happens is the browser is redirected to joeblow.com#aboutus but there is no browser refresh because it is just a hash being added to the end of the url. This enables you to assign #aboutus to the aboutus ajax event. Then lets say I want to order what ever product they are selling so I click on shop which then takes me to joeblow.com#shop which again is just another ajax event assigned to the hash #shop. Now lets say that I forgot where joeblow.com is based out of and I want to go back to about us and I click the back button. This process does not require a page refresh because, again, we are just talking about hashes here, not completely different urls. So what happens is the hash changes in the url and the browser needs the ability to recognize that the hash has changed back to #aboutus so that your listener, ie: "setInterval()" can sense that the hash has changed and call the correlating aboutus ajax function. ie7 doesn't update the location.hash object. In fact, when you navigate back through the hashes, there are absolutely 0 updates to the entire location object in ie7 but it works in every other browser.

I have not come across this use of #hash before and Googled "ajax location.hash IE7".

From a quick read of the responses, the technique appears to be unreliable and is not recommended, though some of the information was several years old and may be out of date.

If you know of a site that uses the technique reliably, then I suggest you take a look at its Javascript to see how it's done.

Airshow

I have been looking for a similar solution for an AJAX application and after reading this post remembered an example that might help you with this. The key here is to use an iFrame to update the history and to store your visible content outside of the iFrame. This allows you to add locations to the history object without the page refresh. Best of luck

Example
http://en.alkoholprofilen.se/

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.