19

Since some time, the SE network has "Hot Network Questions" in a sidebar. Interesting as they are, I click on one of them. It occurs quite frequently that I see another interesting question after having navigated away. When pressing the Back button to see the previous page, I would expect the same list, but the list of questions have changed.

NOTE: this is not a duplicate of the question Ease up on the Hot Network Question Randomness which is about update frequency. Rather, it is about the list being updated even if just navigating through history.

After an hour of trying to make a test case that replicates the HTTP conversation, I have finally found that the issue is related to Websockets. When these are enabled on a page to which you return later, the browser cache is refreshed. This probably affects more than just Hot Network Questions, it effectively prevents caching from working at all!

Browser: Firefox 28 on Arch Linux x86_64.

14
  • If you click the back button then you don't lose the old list... Commented Apr 6, 2014 at 9:27
  • 9
    @benisuǝqbackwards I do lose it. This is Firefox 28 on Arch Linux x86_64, not Private Browsing mode.
    – Lekensteyn
    Commented Apr 6, 2014 at 9:36
  • Alternatively, you could click through on the "Hot Network Questions" title and go to the complete list.
    – asheeshr
    Commented Apr 6, 2014 at 10:28
  • 1
    Weird, I don't lose the list when I hit back on IE11 or Safari. Maybe it's a browser-specific issue?
    – Troyen
    Commented Apr 6, 2014 at 21:43
  • 3
    Why has this been closed as duplicate? It is clearly a bug if pressing Back does not yield the same list. I am fine with refreshing the list on page reload (F5 or following a link), but the list should not change while navigating through history. Please re-open and fix.
    – Lekensteyn
    Commented Apr 7, 2014 at 8:28
  • 3
    @Lekensteyn I don't think this is a bug. Each browser can decide what to do when the Back button is pressed and programmers can't really control that. Your browser decides to fully reload the page, which results in a new list as explained in the linked post. Most browsers will leave the page in the same state, which makes sense, but Firefox got its own way and it's their full right. Commented Apr 7, 2014 at 11:00
  • 2
    @ShadowWizard It must be a bug somewhere. If the browser decides to do a full page reload, then some cache mechanism has failed. Is Firefox faulty? Maybe yes, maybe no, but it is no reason not to find out what is wrong. Otherwise we would be still be stuck with pages that force you to use IE6 because of clearly broken functionality in the page, but "browsers got in its own way and it's their full right".
    – Lekensteyn
    Commented Apr 7, 2014 at 12:53
  • @Lekensteyn what cache? The list isn't cached, every page reload it shows random items from a pool of 100 hot questions. Commented Apr 7, 2014 at 12:58
  • @ShadowWizard Browser cache. The question is not about the randomness of the items, or the preservation of the items on page reload, but rather on navigating back and forward. I have also noticed that the problem does not exist on the /questions page, just on the question page.
    – Lekensteyn
    Commented Apr 7, 2014 at 13:08
  • Right, the problem may be related to Websockets. I am not in a mood to go deeper on this today. Could somebody have a look at this?
    – Lekensteyn
    Commented Apr 7, 2014 at 14:36
  • Still not sure what's going on, but indeed sounds like it's not a dupe anymore. Voted to reopen. Commented Apr 7, 2014 at 14:36
  • It's weird; I actually have noticed this in the past, but at this moment I cannot reproduce it (Chrome, Windows 7), and now I'm not sure if I'm misremembering or if it's truly inconsistent. I will test with Chrome and Firefox on Linux later, perhaps that's where I've noticed it?
    – Jason C
    Commented Apr 7, 2014 at 15:37
  • Or maybe other browsers are at fault? I don't find it unreasonable that a browser considers a page which at some point in time was loaded, and then was (potentially) continuously being enhanced using web sockets, is to be considered outdated when coming back and then not knowing what it might have missed in the meantime.
    – Arjan
    Commented Apr 7, 2014 at 15:41
  • 2
    @Arjan I think "back" has a meaning of "I want to look at something I saw previously" as opposed to just navigating to a page with the same URL as one I went to before. I personally find this very irritating Commented Apr 7, 2014 at 16:11

1 Answer 1

4

As you've found out experimentally, when you hit Back, certain browsers may fail to show exactly the DOM you just navigated away from (which, IMO, is a ridiculously poor usability decision; something I think is a bug but Mozilla WONTFIX this).

Sites which generate/modify DOM via JavaScript will "break" upon the user hitting back unless they are explicitly coded to work around this annoying browser behaviour. Some sites fix this partially, in particular almost every single "related stories" implementation out there has only a partial fix, including Hot Network Questions. They don't make any effort to load the same set of random stories when the user hits Back, resulting in a most frustrating user experience.

StackExchange really needs to implement a proper fix for this, because not all of the popular browsers do the sensible thing here.

6
  • 1
    Browser is crap? Drop support and move on. Why does anybody need to cover up for browser's mistakes? Isn't that prevented by some slavery law or something?
    – bjb568
    Commented Jun 7, 2014 at 5:27
  • 1
    @bjb568 Nobody forces you to fix the browser bug. An end-user does not care which side (browser dev vs web dev) fixes it, as long as the bug is not noticable anymore. The world is not perfect, but as a developer, we can at least try to hide those imperfections.
    – Lekensteyn
    Commented Jun 7, 2014 at 8:32
  • @Lekensteyn Why? It's the browser's choice what to do. The best you should do is file a bug report.
    – bjb568
    Commented Jun 7, 2014 at 13:52
  • @bjb568 Well, I see this in Chrome, and apparently it happens in Firefox too, so those are some pretty major browsers to "drop support" for Commented Oct 8, 2014 at 17:37
  • "Drop support" for that "feature" means don't make special cases for it. I'm not talking about not supporting Chrome/FF altogether.
    – bjb568
    Commented Oct 8, 2014 at 18:46
  • Although I'm a little late to the party: I think the correct thing for a browser to do in this case is to refresh the page. A WebSocket connection must be closed upon navigating away from the page, and returning to it via the history cannot automatically resume it. Therefore the page would be in an inconsistent state that can only be fixed by reloading it. If the page desires a different behaviour it should actively work around that. This is not a browser-specific problem, it's more of a general design problem combining WebSockets and caches.
    – tyg
    Commented May 22, 2016 at 12:22

You must log in to answer this question.

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