I'm programming my own Ajax history library in JS. I ran into problems with IE6 and IE7. Can someone elaborate on why the following is happening?
IE6 & 7
I am able to set the hash values without refreshing the page.
window.location = 'site.com/index.html#' + pageNumber;
I can go to page 1, page 2, page 3, and so on. When I'm on page 3 and hit the back button, I'm not transported back to page 2. Rather, I get completely taken out of index.html! It seems like IE does not think that different hash values are different points in history.
IE7
IE8 in IE7 backwards compatibility mode claims that it has the onhashchange listener.
if ('onhashchange' in window) {
// true in IE7
window.onhashchange = someFunction();
}
However, IE7 never executes someFunction() when the URL changes. This implies that it lies about having onhashchange but never implemented it.
Have you try this: http://tkyk.github.com/jquery-history-plugin/
IE6 and IE7 are known to not support the hashchange event; it looks like you found a bug (?) in the IE7 compatibility mode of IE8.
You need to use a library, like the one in Phong Nguyen's answer, to emulate hashchange support via hidden iframes if you want to use this capability in those browsers. In many cases such libraries will also fix your back button problem; I know the one he linked to does.
Related
I've searched on stackoverflow quite a bit for an answer to this question, but can't seem to find a satisfying one. Using the window.history.pushState() and window.history.replaceState() methods seem to be fairly easy, but to my understanding, they can be used in Chrome, Safari, FF4+, and IE10pp4+.
Is there a way to obtain this effect in IE8+ and FF3+ instead of just FF4+, and IE10pp4+ (plus Chrome & Safari) ?
Without the session history management you can only change the location.hash reliably (no 100% guarantee).
Anything else can't be done without the browser loading another page.
According to this website calling removeChild() in JavaScript causes an Internet Explorer Specific leak called a pseudo-leak.
Sometimes Internet Explorer keeps items in memory after the page is done using them. Although these pseudo-leaks are freed after the user leaves the page, some web pages may be open for long periods of time. To avoid pseudo-leaks, do not use removeChild to remove elements. Instead, set the parent's innerHTML to ""
Does deleteCell() cause pseudo-leaks the same way that removeChild() does?
Edit: I was able to reproduce this error on IE8. Believe it or not, Microsoft claims to have fixed this problem in IE7.
I don't have the benefit of being able to look at IE's source code and confirm, but I imagine if it's anything like how Chrome implements deleteCell, it uses removeChild internally, which could trigger IE's pseudo leak. I know older versions of IE had this issue, but I'm not sure if the current versions do.
From chromium source:
void HTMLTableRowElement::deleteCell(int index, ExceptionCode& ec)
{
...
HTMLElement::removeChild(cell.get(), ec);
}
I'm am doing a JS location.replace in Opera. There is a known bug that the location does not get replaced but updated when only the location.hash changes (see http://my.opera.com/community/forums/topic.dml?id=568931).
I was trying to do the following workaround:
var url = location.href.split("#")[0];
if (window.opera) {
window.history.back();
}
location.replace(url + '#' + newhash);
Unfortunately that does not seem work. Before I start experimenting with setTimeout, I wanted to check if maybe someone has a better idea.
I think the best workaround for this is to not work around it at all.
Reasoning: firstly, the script running in this page should be terminated if I use the back button, or history.back() is called. Hence, in your workaround above the script will (or should) actually stop running before the location.replace() call. We can not remember that you wanted to call location.replace() and do it on the page you've gone back to, because that would be a script injection security issue.
Secondly, even if this workaround worked I would very much recommend not using it. The reason is that Opera will eventually fix its bug. If an end user used a fixed Opera version and a page running your script, each click on one of your links would remove one entry from that user's browsing history..
For a proper solution, you could investigate history.replaceState() - a new method specified in HTML5: http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#dom-history-replacestate
Can you clarify a bit? I took the example from the forum link you posted and uploaded it here: http://people.opera.com/miket/tmp/replace.html. In Opera 11.61/Mac, it appears to work as expected.
Are you seeing something different? Can you explain your problem in more detail?
I'm curious as to how I'd get JavaScript to distinguish between two near identical pages which (as far as I can tell) have the same div's. An example of a page like this would be Google Home Page vs. Google Search Results. Is there anyway I can correctly identify which is which?
In that specific example, window.title will distinguish them. window.title isn't supported by Chrome, but document.title is. It works in Chrome, Firefox, and Opera on both Linux and Windows; Safari on Windows; IE6, IE7, and IE8 on Windows; and probably others as well.
More generally, window.location gives you the URL of the page, which is good for telling what page you're on; more on MDC. It's supported on every major browser I've ever seen, including the list above.
Since HTML5, you can edit the browser history. For example, you can change the current URL with window.history.pushState():
// pushState(state object, title, URL)
window.history.pushState({foo: "bar"}, "page 2", "bar.html");
This makes the user remain on exactly the same page, but changes the URL. This is happening on the current version of Google's homepage too, so the page is still the same.
You can retrieve the URL with window.location.
I have a javascript error at the Safari 4.0.4 browser.
I'm using AJAX navigation for the browser, in order to navigate between the result of my AJAX request, but the problem is that sometimes (i couldn't found the exact reasone) the history.lenght stays at the same count, instead of increase its value.
Thanx :-)
Yes, Safari requires some grotesque hacks for this kind of thing. You could either use a library that has abstracted away all of those hacks, or study it to see how they do it.