Div class is not saved when back button is used

I have an ASP.NET page containing two divs. Both have search fields and a search button contained in each of them. When I first come to this page, Div A has the class "SearchDiv" and Div B has the class "SearchDivDisabled". These classes change their appearance, so the user knows what type of search is currently enabled.

When you click on Div B, JavaScript changes its class to "SearchDiv" and changes Div A to "SearchDivDisabled". It all works like a charm. The problem is when the user goes to Div B, clicks the Div B search button (which obviously redirects to the results page), and then uses the back button. When they return to the search page, Div A turns on again and Div B is turned off, although the last time I used Div B. In the search button event handler, I set the Divs class attribute before redirecting, hoping that this would refresh the pages on the server, so when the user will return, their last allowed Div will still be included (regardless of which one was turned on when the page was first visited).

I believe this is due to ViewState, but I'm not sure why the class attribute is not saved, so when the user returns to the page, it is restored. Is there something I'm missing here, or some simple way to guarantee the behavior I want? Thanks!

Edit: Here is the button event handler code:

protected void RedirectToResults(int searchEnum, string resultPage) { ShowContainer(searchEnum); Response.Redirect(resultPage + this.webParams.getAllVariablesString(null)); } protected void ShowContainer(int searchContainerToShow) { if (searchContainerToShow < 0 || searchContainerToShow > SearchContainers.Count || SearchContainers.Count == 0) return; //disable all search panels foreach (SearchContainer container in SearchContainers.Values) { container.searchDiv.Attributes.Add("class", "SearchDivDisabled"); } //enable selected panel SearchContainers[searchContainerToShow].searchDiv.Attributes.Add("class", "SearchDiv"); } 

RedirectToResults() is called from the actual button event enumerator representing the selected search bar and the URL of the results page. SearchContainers is a dictionary matching an integer with a search div. The important code is the last line, in which I update the selected search container with the "active" search class, and not with the disabled one (which I assign to another div (s))

Additional update: I struggled with this problem for the last couple of days. I could get the following code to work (in page_load):

  Response.AppendHeader("Cache-Control", "no-cache, no-store, must-revalidate"); // HTTP 1.1. Response.AppendHeader("Pragma", "no-cache"); // HTTP 1.0. Response.AppendHeader("Expires", "0"); // Proxies. 

But this is really not a solution, since everything else that is cached correctly is lost, which leaves me worse than when I started. Everything else, apparently, is preserved well, it’s just a diva class that makes me struggle.

Edit: I just want to update this for anyone who comes across this. Although I believe that there is a solution here to set the page cacheability to force the browser to refuse feedback, I could not get it to work 100% with all browsers (basically Firefox gave me seizures, which is a documented error). I believe the cookie solution will work, but I felt that it could be a little more complicated than necessary, just trying to keep the state of the div pair.

What I ended up was to associate the div class with the state of its correlation switch (there are switches next to the div that allow users a more intuitive way to enable search bars). I noticed that these switches retained the correct controlled value when the back button was used, so I could guarantee that they would indicate that the div was turned on correctly. Therefore, in JavaScript onload, I check which switch is enabled, and then change the classes of the search div accordingly. This is a pretty big hack, but it works 100% in all browsers and takes only about 10 lines of JavaScript.

+7
javascript css viewstate
source share
7 answers

Since you are not sending back to change the style of the div, when the user clicks the back button, he will return it to how the page was originally sent. An easy way to fix this is to force the button to trigger a postback that switches the style.

+4
source share

Store this setting in a client-side cookie, then check the cookie using JavaScript on the page load and change the CSS class. Other ways to fix this may not work because the page is not always requested from the server when the user clicks the Back button.

using jQuery cookie plugin

 // this function will update the style of the divs based on the cookie settings function updateClass(){ var val = $.cookie('myCookieName'); // set your div class if (!val || val=='divA') { $('#divA').removeClass('SearchDivDisabled'); $('#divA').addClass('SearchDiv'); $('#divB').removeClass('SearchDiv'); $('#divB').addClass('SearchDivDisabled'); }else{ $('#divB').removeClass('SearchDivDisabled'); $('#divB').addClass('SearchDiv'); $('#divA').removeClass('SearchDiv'); $('#divA').addClass('SearchDivDisabled'); } } // call this passing in 'divA' or 'divB' depending on which is selected function updatePage(selectedDiv){ $.cookie('myCookieName', selectedDiv, { path: '/', expires: 10 }); updateClass(); } // change the class of the divs when the page is finished rendering $(document).ready(function(){updateClass();}): 
+3
source share

I do not think ViewState is a problem; it may be something that is needed to control the client javascript code, since the switching states on the client are not automatically displayed on the server ...

What you want to see potentially is managing your browser history using the history point function: http://msdn.microsoft.com/en-us/library/cc488548.aspx

NTN.

+2
source share

As mentioned in my previous answer, you can get everything you need using session variables. Since you mentioned saving the DIV selection, I asked you to have this in a session variable. If you want to save other form data, as well as reset them all in session variables (make sure you clear them as they complete)

This will be the easiest way to meet your requirements.

Also you use

 Response.AppendHeader("Cache-Control", "no-cache, no-store, must-revalidate"); // HTTP 1.1. Response.AppendHeader("Pragma", "no-cache"); // HTTP 1.0. Response.AppendHeader("Expires", "0"); // Proxies. 

you can just use

 Response.Cache.SetCacheability(HttpCacheability.Private); 

in your Page_load and achieving the same functionality

Let me know if you have any specific problems with this.

+1
source share

This can be solved in two ways.

If each search form is sent to a different URL, each URL must set a session variable called, for example, LastSearchMethd, either "A" or "B". If both of them are sent to the same URL, simply add a hidden field that contains either β€œA” or β€œB” for each form, respectively, and save the passed value in a session variable.

In any case, you need to visualize the style of each DIV, depending on the value of the session variable.

As mentioned by other posters, proper caching will also be considered.

+1
source share

You can save the div identifier that is currently set to the "SearchDiv" class in the SESSION variable, before redirecting to the search button, while loading the search page, get the div and set the corresponding class on it.
That way, you can continue to use javascript to switch classes in divs and save data only before being redirected to another page and avoid unnecessary posts

0
source share

Most changes to the DOM are not saved when you return to a page using the back button in Chrome. (I believe this may be different in other browsers, as they implement BFcache (reverse cache), which is currently being developed for Chrome.)

However, input values ​​such as switches and hidden inputs are retained.
That way, if you save your changes to (hidden) inputs, you can restore the DOM by the pagehow event. (Support for this event looks like this if you check this Mozilla page, but CanIUse.com is more optimistic: https://www.caniuse.com/#search=pageshow )

0
source share

All Articles