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.
Related
We use both onbeforeunload and onhashchange to do two separate things:
1) onhashchange displays a special tooltip asking the user to use application controls for navigation
2) onbeforeunload is used to warn the user that they will loose data if they close the app or try to navigate away to a different URL altogether
This implementation works perfectly on all browsers but IE10. For some reason in IE10, onbeforeunload fires before onhashchange and it causes the wrong thing to display.
Is this a known issue? Is there something special about IE10 I need to know?
Implementation is in Dojo, if that helps...
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 work on an enterprise web application that runs in IE8. It appears blur() is being called on the body causing the IE window to be sent to the background. Unfortunately this code is in a portion of the application that is controlled by the vendor.
Is there any possible way to prevent blur() from being called on the body without modifying the code that is actually calling body.blur()?
Since this is an enterprise application, solutions outside of changes in the application itself are acceptable; Such as changes to IE8 settings, registry, etc.
You should be able to hard code blur to a dummy method. If you can get in before it is called, just call body.blur = function() {}; (assuming body is pointing to your DOM body element).
Using jQuery you could simply block the event :
$('body').blur(function(e) { e.preventDefault(); });
If using Firefox is an option, i have two answers where i propose replacing the function using Greasemonkey.
Using javascript to create a keylistener hotkey for facebook page "like"
Greasemonkey script to replace jQuery plugin function?
If you have to use IE, you might need to change the page itself.
(I know there is Trixie and IE7pro for IE, but never used).
I had an issue when using javaScript editor:CLEditor, if I use jQuery blur() method on it, the IE window goes to the background. CLEditor has it's iframe which has its own body. When you extract that body and use body.blur(), IE browser will go to the background.
Other browsers are not showing that behavior, so it is better to use FF, or Chrome if you are experiencing this.
If you remove body.blur(), probably you would have less problems with IE than you have now, but still you could experience some minor bugs (something is not loosing focus at certain point), but I suppose you could live with it. However if blur() event is enriched with some logic, it could be problem - then find its definition and move logic to some other event that is started with the browser (onload, or ready).
document.body.blur=function(){document.body.focus()}
I change location.hash - in all browsers this behave properly - the page remains original and changes only URL without reload the page.
Pressing Back button behaves differently in Internet Explorer and other browsers. IE does not change the history location.hash and goes to the previous page. Other browsers only change the URL (change the hash).
Is there any way to force IE browser to behave just like the others?
(Moving my comment here and expanding on it a little.)
There are several other questions regarding the #hashtag history quirks with IE.
Essentially, IE doesn't treat different #hashtags as separate entries in its History object.
The best solution appears to be the jQuery History Plugin.
Note- jquery history is no longer maintained and the former maintainers recommend Jquery hashchange
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.