fix: handle negative area results in computeQuadArea

[zeevrosental]

This patch fixes a case in which computeQuadArea calculates the area size correctly, but returns the area as a negative number.
This occurs when DOM.getContentQuads returns quads in a specific order.
E.g. the array: [ { x: 463, y: 68.5 },{ x: 437, y: 68.5 },{ x: 437, y: 94.5 },{ x: 463, y: 94.5 } ] received area size of -676.

[JoelEinbinder]

Thanks for the PR! Do you have a test case that covers this?

[zeevrosental]

My pleasure :-)

There's no problem of creating a test case for this fix.

From what I see it has to depend only on the computeQuadArea function in order to be hermetic.
Because, if the test will depend on DOM.getContentQuads(which is the normal flow), we wouldn't know if it passes because of this fix, or because of a change in the quad order returning from getContentQuads.

Do you write tests in your package that test a single function?
What do you think should be added?

[JoelEinbinder]

A test for this would set up some html/css to produce quads in the right order. Then it would call elementHandle.click on the element with the strange quads, and verify that it indeed was clicked. You can find similar tests in input.spec.js

[zeevrosental]

that's what I thought,

I was concerned that an element like that might stop producing strange quads order in future versions of chromium(because of possible change in DOM.getContentQuads),
which will cause my test not to be hermetic in the long run.

anyway, i'll create a test for this case and add it.
thanks!

[zeevrosental]

Hi, added a test case to the PR.
It seems the node8(macOS) coverage has failed, anything I can do concerning that?

[aslushnikov]

This is awesome, thanks!

[zeevrosental]

My pleasure,

Thanks!