Siarhei Kliushnikau

legacy projects even still with wdio6, and migration require affords. Who knows what are going to be broken after migration. For new projects wdio8 is good choice but for old...

@christian-bromann did you see that wdio6 still are being used? regarding downloads for last week, with wdio7 the same 

> The Selenium manager project is great. Are you asking about a specific feature? No, i meant in general. Maybe have sense implement functionality of the package in selenium-standalone tool...

>Let's just ensure we don't break any functionality if possible. Quite complicated to do so with just pure js :) I think before big changes it should be rewritten to...

> Can you describe this PR a little bit? What are you trying to resolve? What is the approach? Yes sure. Generally it's correct calculations for deltaX and deltaY, previously...

Possible it makes sense to left it just like ``` await browser.action('wheel').scroll({ duration: 0, deltaX: 0, deltaY: 0, origin: this }).perform() ``` without calculation at all, by default it's handling...

thank you for pointing it out @christian-bromann, as we're going to rely on webdriver action native only, there should be fixed an issue with delta https://github.com/webdriverio/webdriverio/issues/11958. I've raised an issue...

the reason why we've added the check was to exclude possible errors with pointer out of bounds. because x offset can be enormous and move pointer to out of viewport,...

@christian-bromann @erwinheitzman @spencerlavallesonos I believe It's because actions will be taking x,y from origin, regarding w3c documentation, not from calculated arguments {x: deltaX, y: delataY}. I suggest {x,y} can't be...

here is reproduceable an example https://github.com/udarrr/moveToExample, please don't see name of the repo as it my old one) moreover it seems wheel actions perform 'nearest' behavior by default for origin