Bug in roundHandlesBoundaryConditions

[LMLB]

In roundHandlesBoundaryConditions, I think the the -0.5 should be positive in the second half (i.e. Math.round(-0.5 + (Number.EPSILON / 3.99)) === 1).

[LMLB]

In any case, the code currently replaces Math.round if Math.round(-0.4999...) isn't equal to 1.

[ljharb]

Can you provide a test case that you think should pass, that fails with our current code?

Indeed I see Math.round(-0.5 + (Number.EPSILON / 3.99)) equalling -0 and Math.round(0.5 + (Number.EPSILON / 3.99)) equalling 1 in most browsers.

Per https://github.com/paulmillr/es6-shim/blob/master/es6-shim.js#L2071-L2072, I checked Safari 8, IE 11, and Opera 12, and got the same results.

git spelunking reveals 55dc1fa → a20e99f → 90c803f, in which I reference compat-table/compat-table#392 (comment), in which @Yaffle indicated this is how the test should go.

@Yaffle, could you confirm that this is the right fix here?

[Yaffle]

The polyfill replaces the native Math.round even if it is good.
The right fix is to remove the second equals operator:

-var roundHandlesBoundaryConditions = Math.round(0.5 - (Number.EPSILON / 4)) === 0 &&
-    Math.round(-0.5 + (Number.EPSILON / 3.99)) === 1;
+var roundHandlesBoundaryConditions = Math.round(0.5 - (Number.EPSILON / 4)) === 0;

It seems it was added by mistake.

[ljharb]

There was definitely a reason that I added the second condition, but if we can't reproduce what it was, then it's probably worth removing it. I'll do so when I have time to rerun tests on all the browsers and versions.

[Yaffle]

@ljharb which tests do you need to rerun? Can I help you?