Going back in time breaks navigation

Gąska

Enter any topic or category (or potentially any other page of the forum).
Set system clock to a time before page load.
You're trapped. All the links, all the buttons, every clickable element doesn't work anymore. You can still post replies and check notifications and like posts and follow users, but anything that takes you to another page is broken. The effect lasts until time is back to the future (relative to page load).

Also reproduced it on main page - but only when I navigated there from somewhere, not when I opened it directly or refreshed. I can start a thread, but it doesn't take me to it after submitting.

hungrier

@gąska Could be because of https. Having the wrong time breaks it completely.

Gąska

@hungrier is there any non-HTTPS forum to test this out?

anotherusername

@gąska there's nothing in the JS console to indicate that there was a security/HTTP error, so I'm inclined to suspect that's not what's happening here.

Plus, Gmail uses HTTPS and doesn't seem to be bothered if I set the clock back.

hungrier

@anotherusername There's probably a threshold for it. I've run into that problem with my parents' PC before, where after a power outage their PC clock had reset itself and some websites (spoiler: it was HTTPS ones) were broken in weird ways. I forget what the exact symptoms were but they were distinct enough that searching for them brought up the possibility that the system clock was making the SSL process fail, and sure enough it was way off, and fixing the time fixed the internet.

Edit: But you're right that that's probably not what's happening in this case, since as per OP's last point, it goes away on its own, while the wrong system time would stay wrong by the same offset.

anotherusername

@hungrier said in Going back in time breaks navigation:

There's probably a threshold for it. I've run into that problem with my parents' PC before, where after a power outage their PC clock had reset itself and some websites (spoiler: it was HTTPS ones) were broken in weird ways. I forget what the exact symptoms were but they were distinct enough that searching for them brought up the possibility that the system clock was making the SSL process fail, and sure enough it was way off, and fixing the time fixed the internet.

I just tried changing it by 3 or 4 hours, and that was enough to break NodeBB.

I'd be totally unsurprised if a clock that was off by years broke HTTPS, though.

that's probably not what's happening in this case, since as per OP's last point, it goes away on its own, while the wrong system time would stay wrong by the same offset.

Yeah, good point.

ben_lubar

@anotherusername said in Going back in time breaks navigation:

I'd be totally unsurprised if a clock that was off by years broke HTTPS, though.

I'm pretty sure HTTPS is only broken by clocks in two situations:

The certificate is valid but the system clock is outside of the validity period. (or vice versa)
The clock skew happens either on the server during the session or on the client during the session handshake. (I'm pretty sure if the client and server disagree on what time it is, the server wins, to prevent replay attacks.)

anotherusername

@ben_lubar said in Going back in time breaks navigation:

The certificate is valid but the system clock is outside of the validity period

That was what I was thinking of when I said it might cause problems if it was off by years. If the system clock reset to 1/1/1970 or something, I'd kinda expect that to cause problems.

hungrier

i don't remember what it was in my case but it was indeed out by years, and probably before any currently active certificates were in effect.

Gąska

@anotherusername said in Going back in time breaks navigation:

I just tried changing it by 3 or 4 hours, and that was enough to break NodeBB.

I changed it by a fucking minute and that was enough to break NodeBB. And sure enough, after minute passed, everything went back to normal.

My gut feeling is that some event queuing mechanism is going nuts when event timestamp is before page load.

anotherusername

Found it.

ajaxify.go remembers the timestamp of when it was called last, and rejects attempts to call it again until the current timestamp is later by at least 500 ms:

  if (i && Date.now() - i < 500) {
    return true
  }
  i = Date.now();

anotherusername

Assuming i isn't used anywhere else (it's not a local variable), a simple boolean lock with setTimeout to unlock it should accomplish the same thing without being affected by the system clock:

  if (i) {
    return true;
  }
  i = true;       /* locked */
  setTimeout(function () {
    i = false;   /* unlocked */
  }, 500);

PJH

@anotherusername said in Going back in time breaks navigation:

Assuming i isn't used anywhere else (it's not a local variable), a simple boolean lock with setTimeout to unlock it should accomplish the same thing without being affected by the system clock:

JavaScript setTimeout and changes to system time cause problems

I've noticed that if I set the setTimeout for 1 minute in the future, and then change my system time to 5 minutes in the past, the setTimeout function will trigger in 6 minutes. I did this is beca...

anotherusername

@pjh I'd consider that a bug, then, although based on the comments, it may be OS-dependent:

0_1510675855397_9d98e656-18a5-45f7-a7cf-c9b24fc8727f-image.png

Timeouts shouldn't be affected if the system clock's time is changed... getting the system clock's time directly, however, will definitely be affected.