The ES5.1 spec for 15.4.4.8 has 'true' as the last argument to the Get/Put/Delete operations in its algorithm, i.e. throw a type error if the element attributes forbid a value change or deletion. test262 does not test for this and of the main browsers Chrome gets this wrong: it correctly blocks the forbidden updates, but silently ignores this instead of throwing an error, and hence also continues reversing instead of aborting.
https://mail.mozilla.org/pipermail/test262-discuss/2013-April/000161.html
From Paul Ruizendaal's email to the discuss thread.
Created attachment 53
Test cases that check true is passed to attributes if not throw a TypeError
Created attachment 64
Test cases that check true is passed to element attributes if not throw a TypeError
As noted in bug description, these 2 test cases fail on v8 debug and release version as it blocks the forbidden updates, but does not throw an error.
[1] The spec algorithm says that reversing progresses until it hits an error: it is not atomic, and an exception halfway through results in a half reversed array (cq. array-like object). Hence, just testing the elements beforehand for blocking attributes and throwing an early error is a no-go optimization.
The proposed tests use a 2 element array to reverse. Using a 4 element array and testing for "semi-reversedness" is a better test choice I think.
[2] Array.prototype.reverse also works on array-like objects. This is not verified.
[3] In real world implementations there is probably a "slow path" implementation that implements the spec algorithm literally and an optimized path for dense arrays. It might be useful to add a test with a dense 50 (or so) element array, just to test something that is likely on a fast path. The counter argument would be that test262 is about spec coverage, not code coverage.