The page uses JavaScript, the user can change the appearance of the page. When you click on a link to another page of the same site and then click on the browser’s Back button, the changes made by the user on the first page are lost.

How to intercept the event return to the page so that you can update it?

  • You do not need to intercept the “back”, but save the changes on the first page (on the backend, or on the client, in local storage or cookies), and restore it when navigating back. - PashaPash ♦
  • @PashaPash or to history - Pavel Mayorov
  • @PashaPash, tell it to the SO developers))) - Qwertiy ♦
  • @Qwertiy unfriendly answers to SO saves the browser, and they scored everything else for simplicity reasons :) - PashaPash ♦
  • Changes on the first page are saved (on the server), but to restore them you need to intercept the return event to the page ... - Peter Varyagin

3 answers 3

In the comments correctly wrote that the answer lies not in the interception of the event "back" from the browser, and the state of the page

For example, a user may change the theme of a page. In localStorage to return to this page, the necessary theme was chosen, we will save it in localStorage

 const savePageState = (name, state) => { localStorage[name] = state; } const loadPageState = (name) => { return localStorage[name]; }

Then, with the events you need, you simply save the data you need to localStorage , and when the page loads ( onload event, for example), you upload the necessary data and use it

  • localStorage will restore the state even if the user does not click "Back" - but will open the page in a new window. The next day. If you only need the processing of the "Back" buttons, then localStorage will not work - Pavel Mayorov
  • @PavelMayorov, it’s not so difficult to add a time check or other conditions to remove a status. - ThisMan
  • one
    But these will be only heuristics that work in a limited number of cases. In general, it is impossible to distinguish between pressing the "Back" button from following a link without using the History API. - Pavel Mayorov
  • With the preservation of the state I am all right, the problem with the restoration, because window.onload is called when clicking Back in IE 11.576, but is not called when clicking Back in FireFox 51.0.1. - Peter Varyagin

Once the user can change the appearance of the page, then javascript is working. When processing user actions, it is necessary to replace the last element in the browser history so that the return will occur on the page you specified (or the same address, but with parameters).

Here is an example .

Script code:

 $('.portfolio_filter').each(function(){ var $this_filter = $(this); $this_filter.on('click', 'a', function(){ var project_type = $(this).data('optionValue').slice(1); var url = window.location.href; if (url.indexOf('?') >= 0) { url = url.slice(0, window.location.href.indexOf('?')); } if (project_type) { url = url + '?type=' + project_type; } // console.log('url: ' + url); window.history.replaceState(null, document.title, url); return false; }); });

When you click a button on a page, the url of the type http://sws-group.zephyrlab.ru/projects/?type=commercial added to the history. After viewing the project of the category commercial, the return is already on the url with ?type=commercial .

  • In this case (processing of any transition by reference) it is better to use replaceState , not pushState . Otherwise, the user will have to press the back button twice to leave this page. - Pavel Mayorov
  • I agree, thanks for the helpful comment - KAGG Design
  • @PavelMayorov corrected the script on the site - KAGG Design
  • As an example, a fairly buggy site is given, especially under the debugger, it did not want to work normally, plus a bunch of minified code that you won’t understand. But what is interesting is that the necessary functionality was there. True, it was not in javascript, but in the Cache-Control header: no-cache, no-store, must-revalidate. I just had Cache-Control: no-cache. - Peter Varyagin

It was not possible to intercept the return event on the page; the problem was solved in another way

I added server-side no-store values ​​to the Cache-Control http-header, must-revalidate, as written here: https://stackoverflow.com/questions/49547/how-to-control-web-page-caching-across -all-browsers

Thus, when you click "Back" the page is automatically updated by the browser without using any additional JavaScript code. The changes made by the user are not lost, because they were previously stored on the server.

When refreshing the F5 page, we also get the latest page status from the server.

If the state were not stored on the server, I would have to add a little JavaScript code (for working with localStorage or cookies), but I would not use history.replaceState. Instead of storing the state (on the client side) in history, it is much more convenient to store the same state in localStorage.