webdriverio: [๐Ÿ› Bug]: ag-grid scrollIntoView bad alignement in v8

Have you read the Contributing Guidelines on issues?

WebdriverIO Version

8.10.1

Node.js Version

v16.14.0

Mode

WDIO Testrunner

Which capabilities are you using?

No response

What happened?

Cell location before scrollIntoView on it

image

Bad alignment to parent when using scrollIntoView on an ag-grid cell on wdio v8.

image

What is your expected behavior?

Same alignement to its parent as in wdio v7 image

How to reproduce the bug.

Repo to reproduce the issue: https://github.com/talbss/wdio-v8-gridRow-ScrollIntoView

npm i npm run wdio

Repo to get the reference correct behavior https://github.com/talbss/wdio-v7-gridRow-ScrollIntoView

npm i npm run wdio

Relevant log output

In v8 (with issue) we have the following:

ag-grid first row first cell location after scrollIntoView() on first row locator: [0-0] firstRowfirstCellLocationAfterFirstRowScrollIntoView: '{"x":0,"y":368}' ag-grid first row first cell location after scrollIntoView() on first row first cell locator: [0-0] firstRowFirstCellLocationAfterFirstRowFirstCellScrollIntoView: '{"x":0,"y":0}' we should have here the same coordinates after the 2 scrollIntoView (cell and its parent row). and we should have the same as in v7 for the same grid (see hereunder), so x whould not be 0 after the first scrollIntoView

In v7 (without issue) we have the following:

ag-grid first row first cell location after scrollIntoView() on first row locator: [0-0] firstRowfirstCellLocationAfterFirstRowScrollIntoView: '{"x":17,"y":326}' ag-grid first row first cell location after scrollIntoView() on first row first cell locator: [0-0] firstRowFirstCellLocationAfterFirstRowFirstCellScrollIntoView: '{"x":17,"y":326}' we can see here that the coordinates are the same after the 2 scrollIntoView. and x is not 0!

Code of Conduct

  • I agree to follow this projectโ€™s Code of Conduct

Is there an existing issue for this?

  • I have searched the existing issues

About this issue

  • Original URL
  • State: closed
  • Created a year ago
  • Reactions: 1
  • Comments: 15 (9 by maintainers)

Most upvoted comments

I have experienced this bug as well. Our solution was to use browser.execute() to call scrollIntoView directly from the browser.

Yes, I can confirm this myself ๐ŸŽ‰ Closing!

is there a reason not to use the browserโ€™s scrollIntoView directly?

Yes, if you are not automating a browser but a mobile environment.