This bug is very much like the most common mistake I see on Common Lisp stack overflow where one tries to mutate constant (quoted) data.

However JavaScript has no similar notion of constant data but implementations try to infer it as an optimisation. In this case that inference was wrong.

I think the memory structure looks something like:

  arr -> box1 -> 1,2,3,4

Reversing:

  arr -> box1 -> 4,3,2,1

But the data occupying the same region of memory before and after the sort. So then when the page is refreshed the JavaScript doesn’t change and the literal data must be included in the “parsed/compiled” form that is reused and so it is initialised as

  arr -> box2 -> 4,3,2,1

The correct behaviour should be as follows:

  1. arr -> box1 -> loc1: 1,2,3,4
  2. Reverse
  3. arr -> box1 -> loc2: 4,3,2,1
  4. Refresh
  5. arr -> box2 -> loc1: 1,2,3,4

The “box” corresponds to the JavaScript object for the array (so mutating the array data can change the box, the data it points at, but not just the reference “arr” as the object might be pointed to from elsewhere). And this box has another pointer to the data for the array (and presumably some bit flag to say whether that is copy-on-write or not). This allows for more efficient array functions when the data doesn’t actually change