Two potential solutions I can think of:

1. Make use of bfcache (thus modified DOM is cached too), which is disabled due to http://bugs.jqueryui.com/ticket/9522 currently.
2. Disable page cache more completely (with no-cache or no-store in Cache-Control), which needs some performance evaluation.

• Bug 58533 has been marked as a duplicate of this bug. ***

Change 226732 had a related patch set uploaded (by Jonas Kress (WMDE)):
Fixes: Using back button in browser loads old version

https://gerrit.wikimedia.org/r/226732

I just tested with removing a sitelink and with adding statement on an other item. In both tests I opened the history and click on back in the browser. The sitelink change was replayed, the statement change was not replayed. Can someone reproduce this behavior? What is the reason for this behavior?

Is that not how the web is supposed to work? I certainly come across this behaviour often enough. And in some cases I rely on it. For instance when not having an internet connection. If the thing then goes reload itself I won't be able to view it at all.

I retested removing of a sitelink. It does not replayed when using the back button.

I agree with Jeroen that the usual browser experience is that with the back button I get exactly the state of the website I've visited before. Automatic reloading doesn't seem to be a nice and intuitive praxis.

How did the MediaViewer team fix this? I think they had a similar issue with the scrollbar jumping top as they lost information about the pervious position after navigating backwards.

The user could confirm a reload first...

In T55466#1487862, @Bene wrote:

I agree with Jeroen that the usual browser experience is that with the back button I get exactly the state of the website I've visited before.

It's actually the state of the website before hitting the save button

@JeroenDeDauw @Bene: I totally agree with your opinion but as @Jonas pointed out, it is actually not showing you the exactly same state as before. Did you read the original bug description?
Let me give you an example:

• Go to any random Wikidata Item
• Assuming the label is "foo", change the label to "bar" and hit save -> the new label is saved and displayed on the page
• Click e.g. the "view history" link or any other link that navigates away from the item
• Click the browser's back-button
• The label of the item is shown as "foo" which is wrong

OK then this can be closed? Either merge or not ....

The steps Tobi listed indeed lead to the wrong behaviour. What you should see is "bar" as the label in this case.

I now tested this and I cannot reproduce this issue on test.wikidata.org. When changing the label, clicking another link and navigating back using the browser's back-button I see the new label as expected. Verified on Firefox 39 and Chrome 44. This is done by the bfcache (https://developer.mozilla.org/en-US/Firefox/Releases/1.5/Using_Firefox_1.5_caching).

Can you tell which browser you're using and where it doesn't work? This seems like a browser-specific issue.

I still can reproduce this behavior on www.wikidata.org with Firefox 39:

• Load an item.
• Change the label.
• Load the page history.
• Use browser's back-button

-> The item is shown again, but without the changed label.

Now I tested with Chrome and there the label kept changed.

Always doing a forced reload is not the way to go. We should try to get to the bottom of this. Perhaps: If we can detect this case, ask the user if they want to reload.

Can't reproduce in Firefox 40.

Change 226732 abandoned by Jonas Kress (WMDE):
Fixes: Using back button in browser loads old version

https://gerrit.wikimedia.org/r/226732