7

In my ASP.NET MVC project, we have introduced Lucine Searching, (Though in this context these details are not required, just giving some background, because I believe my issue has something to do with IE browser and caching).

In this page the user can filter their search based on a keyword. And the user can click to go to the listed out items and come back to the same page with the browser back button or a manual HTML button which has the javascript code, onclick = "location.href = 'Javascript:history.go(-1);'" ).

In Chrome, Firefox and even in Internet explorer 9, user gets back the page where he left off without any issues. I meant it keeps the value the user entered.

However both in IE 10 and IE 11 when the user clicks on the filtered list item it goes into the page and when user clicks either on the browser back button or HTML back button first time I get back the correct filtered page. However when the user again clicks on any of the item, and do the same procedure, I will not get back the filtered value. Instead with all the results, even the text box will not have the keyword entered by the user.

It is always assumes that the back button is there to help the people get back the same page and state where they left. I left with out any clue why IE 10 and 11 acts differently. Could any of you please help me to figure out what I am missing here.

TBA
  • 1,077
  • 5
  • 41
  • 80
  • 2
    Interesting issue. I did a little poking around, out of curiosity, but didn't find much. So, I'll just stick to fixing the issue by telling my users not to use IE. ;) That said, maybe these will help you get further: https://www.webkit.org/blog/427/webkit-page-cache-i-the-basics/ http://stackoverflow.com/questions/2063742/differences-in-internet-explorer-and-firefox-when-dynamically-loading-content-th – SethMW Jan 08 '14 at 16:02
  • Thanks lot Seth for sharing related resources. Let me do some RnD. – TBA Jan 08 '14 at 17:20
  • Different SO question, but the answer seems applicable to your situation: http://stackoverflow.com/questions/18707547/internet-explorer-10-back-button-caching – Ruud Helderman Jan 16 '14 at 12:15
  • TBA, are the pages you go back to using AJAX DOM Manipulation before you move "ahead"? – Dave Alperovich Jan 16 '14 at 16:45
  • Dear @DaveA yes it usses Ajax requests to filter data. – TBA Jan 17 '14 at 05:54
  • Dear @Ruud I believe the question is talking about overriding the default functionality of back button. – TBA Jan 17 '14 at 05:56
  • TBA, I'm not sure if this is your situation, but no AJAX DOM changes would be preserved when going "back" to a screen. Is that your issue? – Dave Alperovich Jan 17 '14 at 15:48
  • @TBA: In fact, that question was the exact opposite of yours. But like I said earlier, you should be concerned with the *answer*, not the question. In particular thomasrutter's reservations about web applications relying on the *back* button; please take that to heart! Also note his suggestion that `Cache-Control` headers may be affecting the behavior you witnessed; please check your HTTP headers with an HTTP analyzer/inspector/debugger, the problem might be there. – Ruud Helderman Jan 17 '14 at 22:08

2 Answers2

2

In special cases (where just the url of the page can not determine state - because of some internal in-page dynamic functionality), We need to implement the history handling for ourselves.

Setting History tokens – Whenever the user takes an action that changes the “screen” in a way that you want to save, you should store a token

  • History.newItem("someLinkTarget", false);
  • Responding to History tokens

Whenever the URL ends in #someToken, that token is passed to the onValueChange method of the History’s ValueChangeHandler

public void onValueChange (ValueChangeEvent<String> event) {
String linkTarget = event.getValue();
if (checkForYourSavedToken(linkTarget)) {
... your code displays your expected results;
} else { … }

This knowledge is from GWT reading though, I did not test this at its core. Please ignore if this does not help you anyway. (Also please find w3schools which suggests that There is no public standard that applies to the history object, but all major browsers support it.

Siva Tumma
  • 1,695
  • 12
  • 23
1

If you're using ajax within the page, then leaving & coming back, that ajax state will be lost. A page does not persist any changes made after it's loaded when you click forward or back.

That's not strictly true though. Forms are persisted and I've used this trick in the past.

Page loads & user does a search which is loaded via ajax. Save the ajax response to a hidden input. When the user leaves the page & returns, the page script detects there is now content in the hidden input & processes this, displaying the previously retrieved results to the user.

Simon Halsey
  • 5,459
  • 1
  • 21
  • 32
  • Concerning ajax/javascript state - It might not be true anymore with IE11 - please look at my research on http://stackoverflow.com/questions/21274085/internet-explorer-11-back-button-javascript-behavior/21274273#21274273. It's only my own findings, so it isn't conclusive, but it would seem IE11 is trying to play around and save the entire page state on back/forward. – PressingOnAlways Jan 22 '14 at 07:23
  • Interesting. I wouldn't have believed you if I hadn't seen the demo you posted. Going to try my own tests now. – Simon Halsey Jan 22 '14 at 22:53
  • Cool, let me know if you find any additional information. I wish MS would publish and document this behavior! – PressingOnAlways Jan 23 '14 at 01:24