Simple case, for comments:

  1. Navigate to a question page that has a link away from the current SE site.
  2. Upvote a comment. [Most probably there’s an issue with flagging as well.] The comment score is updated.
  3. Click the link. [Most probably the link is not essential and any navigation works.]
  4. Click the browser back button to return.
  5. Observe your upvote is not displayed, try to upvote once more.
  6. Get an error popup saying “you cannot mark a comment more than once”, observe that your upvote is still not displayed. Refresh page, observe your original upvote is correctly recorded.

Complex case, for questions and answers (could actually be a feature, or rather a somewhat confusing workaround that wasn’t applied to comments by mistake):

  1. Do steps 1–5 above, but for a question or answer rather than a comment.
  2. Observe what looks like a successful upvote. Refresh page, observe that the question score has (correctly) only been increased once even though you pressed clicked the upvote arrow two times overall.

ETA I’d argue that, even if showing the page as it was when I navigated from it is infeasible, at least the reaction to upvoting an already-upvoted comment should be the same as for upvoting an already-upvoted question or answer: either both should show an error message, or both should succeed.

[Browser: Chromium 64.0.3282.167 on Linux x86-64]

  • 3
    Just refresh the page (before you attempt to repeat the vote). When you go back, it loads the earlier state of the page. The vote is still retained, though. – Catija Feb 21 '18 at 1:39
  • @Catija I recognize that my votes are not lost and the invariants of the site are not broken, but I’d still consider this handling of the back button a bug: the common understanding that it should take me to the page as it was when I was navigating away, not as it was first retrieved from the server. (E.g. browsers preserve scroll state, unless site scripting messes that up [Facebook feed].) – Alex Shpilkin Feb 21 '18 at 1:51
  • 1
    Yeah, I don't think that's how it works. Never has. If you add a comment, move away and then go back, the comment's gone too... same with edits, I think... I'm not sure that it's possible to fix. – Catija Feb 21 '18 at 1:54
  • @Catija Technically possible? Yes, I can think of at least one—rather stupid—solution. But at the very least the behaviour for questions and comments should be the same. – Alex Shpilkin Feb 21 '18 at 1:58
  • I'm not sure what you mean by "behavior for questions and comments should be the same"... but I encourage you to clarify your question if you want it to indicate that the final state of the page should be cached (if different than starting state) in case the user goes "back" to it... rather than focusing on votes alone... and be sure to indicate that you're aware that the content is still there, it's merely serving an old version of the page. At this point, your knowledge is unclear in the question as you've asked it. – Catija Feb 21 '18 at 2:02
  • Please also note that when I say "I'm not sure that it's possible to fix" I mean on this nearly 10-year-old structure. There may be a simple fix but whether that works with the structure here or not is what I question. :) – Catija Feb 21 '18 at 2:03
  • 1
    @Catija Neither of us actually knows, so I’ll leave this for SE devs to mark [status-bydesign] at their pleasure :) – Alex Shpilkin Feb 21 '18 at 2:12

This is true with all page state that does not force a refresh -- post votes, comment votes/flags, and new comments. If you navigate away and then use the browser back button, you don't see those latest updates even though they're there. Your browser is caching this state; there's nothing SE can do about it. (I thought we had this question, but I can't find it if so.)

Note that adding an answer is different; when you submit your answer the page reloads, so if you navigate away immediately after and then return, it's still there. Ditto edits.

When in doubt, refresh the page. I know that's not ideal, but I don't know of an alternative.

| improve this answer | |
  • 2
    To extend on this - there is no alternative. This behaviour is caused by browser caching - I've noticed that Chrome in particular likes to aggressively cache recent history to speed up page loads on back navigation. So, there's nothing SE can reasonably do about it, the solution really is just to reload. – ArtOfCode Feb 21 '18 at 3:41
  • @ArtOfCode thanks for that addition. I've edited it in. – Monica Cellio Feb 21 '18 at 4:00
  • For some fun reading into how ridiculous this can be: You Do Not Understand Browser History – Undo Feb 21 '18 at 4:13
  • @Undo I’ve no problems, actually, with what’s described at that page, except for one thing: “a history mechanism is meant to show exactly what the user saw at the time when the resource was retrieved”, i.e. how the page looked when I navigated to it. I’m arguing that I should see the page as it was when I navigated away. (I’d guess that this passage in RFC 2616 was written before the advent of browser scripting, when there could possibly be no difference between the two, and then stuck.) – Alex Shpilkin Apr 2 '18 at 17:37
  • Hm. It appears that NN 2.0 beta with the first version of (what would become) JavaScript came out in 1995, while this passage first appears in RFC 2068 §13.13, published in 1997, and first browsers with scripting date back to 1992. (RFC 1945 §10.7 documented history lists much more loosely.) Still, there’s a difference between browser scripting being possible and it being important enough to enter into the documentation for HTTP. (XMLHttpRequest shipped in 1999.) – Alex Shpilkin Apr 2 '18 at 17:48

Not the answer you're looking for? Browse other questions tagged .