[1.15] Fix precision loss (int vs float mixup)

[divinity76]

The origin X/Y comes from Page.getLayoutMetrics.cssContentSize ( https://chromedevtools.github.io/devtools-protocol/tot/Page/#method-getLayoutMetrics ) which returns float values like -0.666748046875 , not integers, but the library erroneously treated it like integers, that can cause Mouse()->find(...)->click() to miss-click on very small targets, and with custom error handlers it can also cause

["trace":"Exception":private]=>
    array(9) {
      [0]=>
      array(4) {
        ["file"]=>
        string(52) "C:\temp\vendor\chrome-php\chrome\src\Input\Mouse.php"
        ["line"]=>
        int(338)
        ["function"]=>
        string(9) "{closure}"
        ["args"]=>
        array(4) {
          [0]=>
          int(8192)
          [1]=>
          string(69) "Implicit conversion from float -0.666748046875 to int loses precision"
          [2]=>
          string(52) "C:\temp\vendor\chrome-php\chrome\src\Input\Mouse.php"
          [3]=>
          int(338)
        }
      }

(and that is exactly what happened to me and how I noticed the problem)

[divinity76]

is it possible that float scroll position is a recent change in chrome itself? seems much of the code is written with the expectation that scroll position is int, not float 🤔 but window.scrollY is float (and very floaty like X.5), not int

[divinity76]

fixing this actually requires breaking the public api a little bit: $page->mouse()->getPosition()
used to return array(int, int); but when fixing this it returns array(float, float) 🤔

[enricodias]

This would change the public api, although changing to float shouldn't be a breaking change and old implementations using integers should still work 🤔

But if those tests shouldn't fail.

[stale]

This issue has been automatically marked as stale because there has been no recent activity. It will be closed after 30 days if no further activity occurs. Thank you for your contributions.

[divinity76]

@enricodias fixed the testcases. (some were expecting int but getting float. no failures beyond that)

[GrahamCampbell]

This is a breaking change, when the caller has strict types enabled.

[divinity76]

commented on wrong line, but yes. the actual api break is on line 34, 35 and 338.
strict_types have an exception for implicit int->float, so line 57 is not an api break: https://3v4l.org/gS1b7
thus function move can be upgraded to support float without breaking api,
but function getPosition() and getMaximumDistance() cannot.

Would you prefer to only fix the

Implicit conversion from float -0.666748046875 to int loses precision

issue, at least for the remainder of v1?

[enricodias]

Why is getMaximumDistance a breaking change if it's a private method? And getPosition returns an array with no defined types, not even in the docblock.