Change page URL without refreshing - is there a cross-browser solution? - javascript

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.

Related

Javascript location.replace bug in Opera

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?

Site works in Firefox and Chrome but not Internet Explorer

Apologies but this is not a programming question, but it may have a programming answer.
For some reason my site, http://pctools.alwinsights.com will not display properly in IE (I'm using version 8) but it's fine in firefox and chrome. The content does not appear in the centre of the screen in IE and also generates two JS error messages while the pages are loading.
I've tried enabling Active X and Scripts in the security settings but with no joy. I've also looked around the net but cannot find an answer, well not one that works!
Unfortunately I know nothing about javascript so really don't know where to start with the error messages that are generated.
Any help appreciated.
regards
Nigel
Update:
OK initial error has gone, I'd screwed up with a directory name - apologies.
I've found out that if I disable the option to display the last twitter feed in the wordpress theme it loads OK. So it is the JS code in a php script called thememx-document.js that is causing the error. The code generating the error is "var twitterHtml = jQuery.cookie(twitterCookieName);" It says it's charcater 4, which is a space but I don't understand this.
I can live without Twitter on this site but it still leaves issues as to why content isn't centred nor the pop-up ad is not showing (compare to Firefox) but this may not be a programming issue that warrants a question on this site.
Thanks to all for your comments and input.
Nigel
Start with valid code; a validator will pick up lots of problems. Among yours is content before the Doctype, which triggers quirks mode. Quirks mode causes browsers to emulate bugs in ancient browsers and become much more inconsistent with each other. One of the emulated bugs in Internet Explorer breaks standard centring techniques.
for not properly disply-- its the problem of CSS ...IE7 and IE8 dosen't support css3.so you should simply make another css stylesheet for IE and call it on page only if someone visit your site using IE. and for other broswers it will show exiting style.
and abot JS error --you should check all your php coding and then fix it. its not JS problem. if you are not familar with PHP coding then i am here to offer my free service to you or anyone else. i will help you as i can.
First, having problems with any version of IE is expected and the norm. IE is the worst browser on the planet.
You have a link element on your first line. Links belong inside the head element. Placing it on the first line throws IE into 'quirks mode' and then IE becomes even worse than it normally is.
Good.
OK, maybe your site has to work for IE. 9 times out of 10, the problem is a terminal comma. The following is understood in real browsers but generates an unintelligible error in IE:
var x = [ 1, 2, 3, ];
The tenth time (in my experience), it's string indexing.
var x = "abc";
var c = x[2];
In a real browser, c is set to "c"; in IE, another unhelpful error message.
If this helps, remember: in IE, it's very important to create as many circular dependencies as possible. That is, attach to DOM elements JavaScript functions that have references to other DOM elements. IE fails to clean up such dependencies when the user leaves your site and so leaks memory. Once it leaks enough memory, IE slows and eventually freezes the OS and the user learns a valuable lesson: don't use IE. (Microsoft has a good page explaining how to do this although, inexplicably, they recommend against doing it.)

distinguishing between pages using JavaScript

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.

Ajax history on IE6/7 is broken

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.

window.location.hash at Safari 4.0.4 doesn't increase the history.length

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.

Categories

Resources