[🐛 Bug]: element.scrollIntoView() throws "Request failed with status 500 due to move target out of bounds: move target out of bounds"

[spencerlavallesonos]

Have you read the Contributing Guidelines on issues?

• I have read the Contributing Guidelines on issues.

WebdriverIO Version

latest

Node.js Version

18.17.1

Mode

WDIO Testrunner

Which capabilities are you using?

N/A, not configured from initial wdio wizard.

What happened?

When using element.scrollIntoView() the error/ warning "Request failed with status 500 due to move target out of bounds: move target out of bounds" is thrown even if the scrollIntoView() is executed successfully

What is your expected behavior?

If a move target is in boundary (is currently on the screen and visible), scrolling to it shouldn't throw an error that the target is out of bounds.
In this example Sonos.com's main "Shop" button on the top navigation-bar.

How to reproduce the bug.

Clone this repo, follow the readme, see the output.

Relevant log output

npm run wdio

> wdio
> wdio run ./wdio.conf.js


Execution of 1 workers started at 2023-12-13T23:48:54.651Z

[0-0] RUNNING in chrome - file:///test/specs/wdiobug.test.js
[0-0] Will trigger "Request failed with status 500"
[0-0] 2023-12-13T23:49:09.006Z ERROR webdriver: Request failed with status 500 due to move target out of bounds: move target out of bounds
[0-0]   (Session info: chrome=120.0.6099.71)
[0-0] PASSED in chrome - file:///test/specs/wdiobug.test.js

 "spec" Reporter:
------------------------------------------------------------------
[chrome 120.0.6099.71 mac #0-0] Running: chrome (v120.0.6099.71) on mac
[chrome 120.0.6099.71 mac #0-0] Session ID: 6a5c6510f6bd7785d1caf445b04e4656
[chrome 120.0.6099.71 mac #0-0]
[chrome 120.0.6099.71 mac #0-0] » file:///test/specs/wdiobug.test.js
[chrome 120.0.6099.71 mac #0-0] WDIO Bug
[chrome 120.0.6099.71 mac #0-0]    ✓ element.scrollIntoView() still sending status 500
[chrome 120.0.6099.71 mac #0-0]
[chrome 120.0.6099.71 mac #0-0] 1 passing (14.7s)


Spec Files:	 1 passed, 1 total (100% completed) in 00:00:17

### Code of Conduct

- [X] I agree to follow this project's Code of Conduct

### Is there an existing issue for this?

- [X] I have searched the existing issues

[erwinheitzman]

This seems like an error in the logs and not an error in the test

[wdio-bot]

Thanks for reporting!

We greatly appreciate any contributions that help resolve the bug. While we understand that active contributors have their own priorities, we kindly request your assistance if you rely on this bug being fixed. We encourage you to take a look at our contribution guidelines or join our friendly Discord development server, where you can ask any questions you may have. Thank you for your support, and cheers!

[udarrr]

@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 used with origin it's always will be error.

https://www.w3.org/TR/webdriver2/#wheel-actions

Let (x, y) be the result of trying to get coordinates relative to an origin with source, x offset, y offset, origin, browsing context, and actions options.

If x is less than 0 or greater than the width of the viewport in CSS pixels, then return error with error code move target out of bounds.

If y is less than 0 or greater than the height of the viewport in CSS pixels, then return error with error code move target out of bounds.

i've tried my assumption and it's working the same but without error and fallback

instead of

 await browser.action('wheel')
            .scroll({x:deltaX, y: deltaY, origin: this })
            .perform();

this one

browser.action('wheel').scroll({ origin: this }).perform();

[udarrr]

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

[erwinheitzman]

@udarrr thanks, I have already put my name on the issue to look into it when I can

[WillBrock]

I'm noticing this issue as well while I'm updating to v8.

I may take a look at some point after I fix some other things.

[erwinheitzman]

I actually am unable to reproduce this with the examples given, @WillBrock do you have a simple reproducible example for this?

[spencerlavallesonos]

@erwinheitzman You're unable to reproduce the bug even with the repo I linked in my initial issue summary? I just cloned, ran npm install then npm run wdio and was able to confirm it's still happening.

[erwinheitzman]

@spencerlavallesonos you're right, I didn't check the logs.

I'll refer back to my answer here: #11866 (comment)

Logs are logs, they are meant for debugging purposes only like in any other piece of software.
Something went wrong yes, and WebdriverIO handled it correctly.

[spencerlavallesonos]

@erwinheitzman If something is wrong with logs, shouldn't that be addressed? The issue I'm reporting is that these printouts are present when there's no evident issue interacting with the element. If this is the correct interaction, we should suppress the logs or fix the cause for the logs.

[christian-bromann]

As long as the errors are not printed to e.g. stdout and give a wrong impression that something actually is wrong I am alongside @erwinheitzman that logs should show what actually happens during the test. If WebdriverIO retries certain errors then it should log those errors too.

[nrstaber]

I am confused, in my tests I see this error, but then my tests pass. If there was an error in the log why are my tests passing?

[christian-bromann]

in my tests I see this error

How do you see this error, mind providing a screenshot?

If there was an error in the log why are my tests passing?

Because WebdriverIO tries different things to achieve what you are trying to do. It uses WebDriver's action API first to attempt scrolling the element into view. We do this as we believe it is the closes way to a user interaction. If we fail due to the error mentioned in the OP, we fall back to use the Web API for it which does the job but is not our preferred solution since no scroll events are fired.

Again, as long as these errors are in the log files only, it should be fine.

[nrstaber]

Here is the log and the next image is the spec reporter that shows the test has passed.

[christian-bromann]

@nrstaber are these logs from your terminal or an excerpt from a file?

[nrstaber]

Yes. I got all for this one thread.

[0-10] RUNNING in chrome - file:///Header/ClickItemfromMMenu.js
[0-10] 2024-02-10T00:18:49.136Z ERROR webdriver: Request failed with status 500 due to move target out of bounds: move target out of bounds
[0-10]   (Session info: chrome=121.0.6167.86)
[0-10] 2024-02-10T00:18:51.763Z ERROR webdriver: Request failed with status 500 due to move target out of bounds: move target out of bounds
[0-10]   (Session info: chrome=121.0.6167.86)
[0-10] PASSED in chrome - file:///Header/ClickItemfromMMenu.js
[chrome 121.0.6167.86 windows #0-10] Running: chrome (v121.0.6167.86) on windows
[chrome 121.0.6167.86 windows #0-10] Session ID: 263c1d88630146f6bff81b7a415ea0ba
[chrome 121.0.6167.86 windows #0-10]
[chrome 121.0.6167.86 windows #0-10] » /Header/ClickItemfromMMenu.js
[chrome 121.0.6167.86 windows #0-10] Click Item from Menu
[chrome 121.0.6167.86 windows #0-10]    ✓ run automated test
[chrome 121.0.6167.86 windows #0-10]    ✓ Getting imports
[chrome 121.0.6167.86 windows #0-10]    ✓ Click on Mini
[chrome 121.0.6167.86 windows #0-10]    ✓ Click on Immigration
[chrome 121.0.6167.86 windows #0-10]
[chrome 121.0.6167.86 windows #0-10] 4 passing (11.2s)
[chrome 121.0.6167.86 windows #0-10]
[chrome 121.0.6167.86 windows #0-10] Check out job at https://app.saucelabs.com/tests/

[christian-bromann]

I see, yes, these error messages should be suppressed.

[erwinheitzman]

@christian-bromann these errors are only shown because when you do not specify a outputDir (which is the default) all the logs are shown in the terminal as the default logLevel is set to info iirc.

Setting the outputDir gets rid of the logs and thus the error.
I was thinking of updating our default settings to have a default outputDir to output to.

[christian-bromann]

@nrstaber can you verify that you don't have outputDir set in your WebdriverIO config?

[nrstaber]

I can verify that I don't have outputDir in my config.

[christian-bromann]

@nrstaber can you verify that you have logLevel set to error?

[nrstaber]

Yes, it is set to error.

[christian-bromann]

Gotcha. So yeah in this context the error message can be confusing but I don't really have an idea what would be a better approach. Any feedback would be appreciated.

[spencerlavallesonos]

I would think it should be suppressed as logLevel: error should indicate it only logs actionable errors. In this case, there's nothing actionable for the engineer working on tests that print out this message.

[erwinheitzman]

@spencerlavallesonos logLevel: silent already does that as well as setting the outputDir. You get an error when there is an actionable error. The logs just contain every command sent to the driver and more, the errors you see are an error thrown when sending the command to the driver, we catch it and resolve the situation so no action is needed. Say you take the example of making a mistake in the code, it will throw an error regardless of the logLevel as the logLevel applies to the driver logs and not the wdio logs.

I think we can certainly make improvements so let me list what I think are things we could work on.

Takeaways for us:

• I would like to set outputDir to a default value so that we do not pollute the terminal as well as prevent this kind of confusion in the future
• I think we should revisit the logLevel and it's influence at some point

My advice to you:

• I advice to already use the outputDir in your project

[christian-bromann]

Something I suggest to add to the list is amend the error message to tell folks that this error message can be ignored as WebdriverIO attempts to recover from it. It might even make sense to change the logLevel here to debug.

[spencerlavallesonos]

@erwinheitzman

You get an error when there is an actionable error.
the errors you see are an error thrown when sending the command to the driver, we catch it and resolve the situation so no action is needed.

I agree with @christian-bromann that this 500 error shouldn't be included in logLevel: error regardless of outputDir being set because as stated above, the error isn't actionable.

[udarrr]

I'm wondering if there is a chance to have an example where we can use current implementation without the error

I'd suggest that we can't use x: deltaX, y: deltaY with origin:this simultaneously in

scroll({ duration: 0, x: deltaX, y: deltaY, origin: this }) 

i believe it should be something like just deltaX, deltaY (integer) in

scroll({ duration: 0, deltaX, deltaY, origin: this }), 

[WillBrock]

This sounds similar to the no alert error that prints to the console. We don't set the outputDir when running tests locally because it makes sense to see everything in the console when things fail.

We just updated to v8 and we see these errors in the console and multiple devs have reported it as errors when running their tests when it is not an error. In v7 this did not happen. It just clutters the console and makes things look like they fail but they pass.

I'm not sure the best approach but I think we should suppress them somehow.

[christian-bromann]

@WillBrock I pushed a release yesterday which included #12383 that should resolve the issue. I think we can close the issue.

[WillBrock]

Awesome, thanks!

[ivanovicuros]

After updating to the latest release the error still display in terminal.

[christian-bromann]

After updating to the latest release the error still display in terminal.

Can you share a screenshot?

[ivanovicuros]

[christian-bromann]

@ivanovicuros can you make sure to update all your WebdriverIO dependencies (make sure you nuke your package-lock.json and reinstall everything)? As mentioned above this should be fixed now. If you still see this after updating, mind providing a reproducible example?

[WillBrock]

@christian-bromann #12383 changes some of the hardcoded errors but not the move target out of bounds error so I don't think that will have any affect on this error. I only see that error referenced in a type in localTypes.ts so I think it's coming from the server and not something in the wdio code. I think this is the same type of thing where you get the browser alert errors in the console when they are really not errors to the end user, with this error it just happens a lot more. I don't know if we can listen for certain types of errors and then do a warn on those instead so they are not logged to the end user in the console.

I updated to 8.32.4, removed node_modules, package-lock and npm i but still have the error.

[christian-bromann]

@WillBrock interesting, do you have a minimal reproducible example for this?

[WillBrock]

It's just the same thing what the original poster put in the description with the repo linked.

https://github.com/spencerlavallesonos/wdio-bug-scrollIntoView

[spencerlavallesonos]

Confirmed still happening even when updating my test repro repo to latest wdio release @christian-bromann
https://github.com/spencerlavallesonos/wdio-bug-scrollIntoView

[christian-bromann]

I pushed another fix that removes the error message.