We noticed regressions and inconsistencies after migrating from 0.18.1 to 0.19.0

Hello folks,

we are trying to upgrade an existing project to splinter==0.19.0 but we are running into a lot of issues.

We are aware of the deprecations you introduced (the warning was quite useful) so we migrated all the existing code like this:

context.scenario_browser.is_element_visible_by_xpath("//a[contains(text(), 'Log In')]", 30)

to this:

context.scenario_browser.find_by_xpath("//a[contains(text(), 'Log In')]").is_visible(30)

and the weird thing is that some checks still work as they were working with 0.18.1 while some others give us a mix of these issues:

the same document which can be parsed with 0.18.1 now with 0.19.0 needs a time.sleep(1) (or even longer) otherwise the document isn't ready
it seems that the wait_time parameter is completely ignored: if we use a breakpoint() and debug the code step by step, everything works fine because by running it step by step we manually introduce slowness and by the time we run the next line of code, the element is ready to be parsed.

Considering that we haven't done any other change to our code (the initial PR was made by Dependabot which just bumped the dependency number and I only changed the syntax by following the warning message) we can't really understand why the same code doesn't work anymore.

Are you aware of any similar regression or do you know if there is something we should do to make sure the document is fully loaded before we try to access any of its elements?

Thank you so much.

When you say the wait_time parameter is ignored, have you observed this with your eyes? Does nothing happen for 30 seconds or does the script appear to continue?

The implementation of is_element_visible_by_xpath applied the wait_time argument to both the find element operation and the visibility check. find_by_xpath().is_visible(30) will only apply the wait_time to the visibility check. This behaviour is correct but wasn't documented. This may be the source of your issues.

You can use the wait_time argument with find_by_<x> methods or apply it at the Browser level. This is undocumented at the moment but should be in the future.

When you say the wait_time parameter is ignored, have you observed this with your eyes? Does nothing happen for 30 seconds or does the script appear to continue?

the script appears to continue. It doesn't wait for the element to be available, but it immediately spits errors like ElementNotFound or "the element has been removed from the DOM" etc...

I can provide more information and additional debugging information on Monday when I'm back to work.

Thanks for your reply in the mean time 🙏

The implementation of is_element_visible_by_xpath applied the wait_time argument to both the find element operation and the visibility check. find_by_xpath().is_visible(30) will only apply the wait_time to the visibility check. This behaviour is correct but wasn't documented. This may be the source of your issues.

You can use the wait_time argument with find_by_<x> methods or apply it at the Browser level. This is undocumented at the moment but should be in the future.

we tried that too (yes, I confirm the documentation is not updated but we dug into the source code to find out) but it didn't help. I will collect more information in the next days, thanks again.

@jsfehler

@jsfehler hi, I finally had the possibility to do some tests and I tried to do what you said (add the wait_time parameter to each call), but it still doesn't work.

Our code does the following checks (they may be redundant, possibly, but they were working with 0.18.1):

browser.find_by_css("[data-testid=signup-form-expand]", wait_time=30).is_visible(30)
browser.find_by_css("[data-testid=signup-form-expand]", wait_time=30).first.click()

browser.find_by_id("id_email", wait_time=30).is_visible(30)
browser.find_by_id("id_password1", wait_time=30).is_visible(30)

password = password or TEST_PASSWORD
browser.fill("email", email)
browser.fill("password1", password)

browser.find_by_css("[data-testid=signup-form-submit]", wait_time=30).first.click()

If I put a breakpoint() at the beginning and then I continue the execution by pressing c (so in this way I introduce a bit of lag and give it time to load the page), everything works as expected.

If I remove the breakpoint() I get this error:

HOOK-ERROR in before_feature: ElementNotInteractableException: Message: Element <input id="id_email" class="field__input" name="email" type="email"> could not be scrolled into view
Stacktrace:
WebDriverError@chrome://remote/content/shared/webdriver/Errors.jsm:183:5
ElementNotInteractableError@chrome://remote/content/shared/webdriver/Errors.jsm:293:5
interaction.clearElement@chrome://remote/content/marionette/interaction.js:344:11
clearElement@chrome://remote/content/marionette/actors/MarionetteCommandsChild.jsm:194:17
receiveMessage@chrome://remote/content/marionette/actors/MarionetteCommandsChild.jsm:87:16

p.s: when you say "or apply it at the Browser level" (regarding wait_time), how does it work? Do you have any example I check? Thanks

@jsfehler

@jsfehler hi, sorry to bother you, I was wondering if there were any updates on your side for the above issue. Thanks 🙏

I think I might have a related issue I've been seeing. If unrelated, I can open up a separate one.

I have some tests which are hanging and waiting indefinitely whenever the element cannot be found. This happens if I'm writing a test first, before I've actually implemented the feature.

For example:

print('visit page')
table = self.browser.find_by_css('#result_list')
print('table')
rows = table.find_by_tag('tr')
print('rows')
row_1 = rows[0]
print('row_1')
row_1_text = row_1.find_by_tag('td')[5].text
print('row_1_text')
self.assertEqual(row_1_text, 'Yes')

Printed in the console before the test hangs:

visit page
table
rows
row_1

I would expect the row_1_text = row_1.find_by_tag('td')[5].text line to throw an error because the table does not have a column at that index yet. Once I add that column, the test passes. I have tried adding a wait_time to the find_by_tag call and I have also configured the browser with a wait_time of 1 second: Browser('chrome', config=config, wait_time=1).

Has anyone encountered this issue with the wait_time not being respected?

@andreagrandi

@andreagrandi Apologies for the extremely late answer: The ElementNotInteractableException error is an issue with your test. You can't fill an input if it's not interactable. It's difficult to triage this without access to the application you're testing, but it's not a splinter/selenium issue. Visibility and interactive states are different. If I had to guess, there's some async behaviour happening where an element is technically visible before it's interactable.

However, I've fixed the issue where you were getting ElementDoesNotExist errors. The new logic in the is_visible() and is_not_visible() methods did not account for the element being removed after the element was first found. #1277 handles this. I'm making an assumption here, but if your application is removing and adding elements then you would have encountered this issue.

@nburt

@nburt This sounds like a separate issue. We'll also need a traceback to see the error message your code is throwing.

Navigation Menu

Repository navigation

We noticed regressions and inconsistencies after migrating from 0.18.1 to 0.19.0 #1138

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

We noticed regressions and inconsistencies after migrating from 0.18.1 to 0.19.0 #1138

Description

Activity

jsfehler commented on Feb 3, 2023

jsfehler commented on Feb 3, 2023

andreagrandi commented on Feb 4, 2023

andreagrandi commented on Feb 4, 2023

andreagrandi commented on Feb 6, 2023

andreagrandi commented on Feb 22, 2023

nburt commented on May 22, 2024

jsfehler commented on May 24, 2024

jsfehler commented on May 24, 2024

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions