I have a page with a few hidden fields in it. Those get filled with values by a script (JS/jQuery) when the user has finished selecting a couple of options.
Now, if I click a link on that page, go to the linked page and then hit the back-button, FF and Safari are able to read out the values of the hidden fields. So the function to read out the values seems to be correct (it's not complicated anyway).
But IE (and also Opera, even though I set history.navigationMode to compatible) shows me empty values, even though I can see the correct values in the generated sourcecode of IE.
I also added a test function, to show me the values onunload, which worked fine. But hitting the back-button IE still doesn't "recognize" them.
I have no idea what the problem here is. Anyone?
Thanks!
Actually, Firefox even keeps current values when hitting refresh, while IE resets page to initial values on refresh. I guess this is same stuff. No standards describe what should actually happen here, so you should not rely on how the different browsers choose to handle this scenario.
You are relying on the browser filling the in correct form fields automatically when re-entering a form using the back button. AFAIK, only FF and Safari do this by default. Whether it can be activated in IE and other browsers, I don't know. Anyway, you can't rely on it in the wild.
You may have to work around this using Cookies. You would have to set cookie values onchange or onunload, and read out the cookie values when your page loads.
Related
Here's how it works in Safari on iOS (and this is the behaviour I want):
If I enter some text into a text field on a page, click a link on the page which loads another page and then returns to the previous page using the back button, the text I entered into the text field is still there.
Using Chrome on iOS, this does not work, however. The textfield is empty when returning to the page.
Is there an explanation for this and is there a solution? Using localeStorage and a cookie to cache the form data doesn't feel like a good solution, as I have to keep track of when that data should be removed from the cache.
I have the same issue. After much researching and testing, I concluded that it's a bug for Chrome. I hope Google will fix it soon. Here's the bug report I logged:
https://code.google.com/p/chromium/issues/detail?id=470398
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).
We have a problem with IE. On a web page with a form, multiple frames are created via javascript. This is due to some crappy WYSIWYG. The problem is that when the user clicks on the browser "back" button, you'd expect the entire page to go back. This is what happens in FF, Chrome, Opera, Safari, etc. But for IE, you have to click the back button for each frame on the page, even if you don't do anything else but load the page.
Knowing that sometimes +20 frames can be on the same page (many textfields), this is a real pain for users.
The question: how do you make the browser back button work for the main page, regardless of the amount of frames you have on the page ?
Thanks so much !
One way of doing it is to implement clientside routing using hash bang urls.
Every time a page is changed on an iframe the hash part of the parent url is changed to reflect it.
You then have some js that listens for these changes and does what is needed to updated the full page state across frames.
Now when the user pushes the back button, the parents url changes to the hash it was before the last change in the child iframe, and everything is updated accordingly.
Be aware: that this is a non-trivial thing to implement if you have many iframes, and i can't give you a working script that will fix your problem. This is meant for inspiration only.
(following Martin Jespersen response)
Yes, I also thinks that it is only solution. And it is hard to implement, but there is a lot of good libraries to handle # changes.
The lightweight jQuery solution: http://tkyk.github.com/jquery-history-plugin/.
Very complex solution with ExtJS: http://dev.sencha.com/deploy/dev/examples/history/history.html#tab1:subtab1.
And I think, that is not possible to do it realibly cross-browser without javascript.
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.