-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How to suppress stale element reference error? #2584
Comments
Unfortunately, I never found a way to "suppress" these errors in Nightwatch. However, I did find a way to execute Javascript directly which allows you to use try/catch to suppress the errors. Here's an example ...
|
#2632 It will be fixed in the next patch version |
Duplicate #2527 Closing this one |
Reopening, waiting on @kretschmannj to confirm. Please add your specific test case as well according to this format, i can try and run on my local to verify. |
I opened this ticket 2 months ago and now, I'm not so sure that suppressing the error is the right thing to do. The 'elements' command, which is run as a precursor to commands like 'click', retrieves an element ID that is then used in the subsequent command. If the DOM is refreshed between the time that the element ID is retrieved and the time that the 'click' command (for example) is executed then I would expect the 'click' command to fail. I have since realized that the correct way to handle this situation is to identify what is causing the DOM to refresh (in my case a background process that is causing a page spinner to display) and then wait for that situation to pass (i.e. wait for the spinner to go away). Therefore, I think this issue could be closed unless someone feels otherwise. |
I've encountered this same issue and had to work around it multiple times now. In single page applications (like React), it's not unreasonable for an element to be unloaded from the page and then re-enter with a new value, and it would be great if Nightwatch could recognize that the element ID it's holding on to is stale and to fetch a new one. |
@MicahLC have you tried this in v2-beta? we have improved the behaviour. |
@beatfactor I have not yet, I'm trying to update to v2 but running into various issues. |
@MicahLC Ok, let us know in the Discussions if there's something we can do to help. |
This is an issue with V2. Can we reopen this issue |
Come here to echo deepikaG5 We are still in need of a way to capture an element after the whole or part of the DOM is reloaded. |
For the record, kretschmannj's suggestion to "identify what is causing the DOM to refresh... and then wait for that situation to pass" is not sufficient, it still poses another race condition. If the spinner comes and goes too fast, this cant be relied on to know when a state change has taken place. We run into this very example with our app frequently where we wait for the spinner to no longer be visible to know when the state has changed but sometimes it comes and goes so fast Nightwatch/the test thinks there was no state change. |
Please consider looking at the following for inspiration to at least help developers by exposing some tooling to observe DOM mutations, if not providing more readily packaged implementation behind nightwatch API commands. https://stackoverflow.com/questions/3219758/detect-changes-in-the-dom |
Under the covers, many Nightwatch commands first run an 'elements' command to get the element ID and then they run the actual command (click, visible, etc). If the DOM is refreshed between the time that the 'elements' command is run and the time the actual command is run then a stale element error is thrown. I see this all the time, especially when dealing with dynamic elements like page spinners. Is there a way to suppress this error?
Nightwatch v 1.5.0
The text was updated successfully, but these errors were encountered: