deflake Control.click and Control.selectDropdownMenu
#619
Conversation
on some systems clicking a button will fail as the button is obscured by the "Save"/"Apply" buttons in configuration. whilst Selenium scrolls it appears as though the click is done whilst the scrolling is still in progress (the diagnostic screenshot shows everything is ok) but this is taken very shortly after the test failure. With this just try and click a few times if the button is obscured. Ideally we would re-write the Jenkins UX so that the Save/Apply buttons did not float above other parts of the form but rather where at the bottom and the form contents would stop above the buttons. but that is not such an easy fix so for now just try a few times,
on some systems the menu would fail to be displayed when we tried to click on it as it is shown asynchronously. with this change we wait for it to be visible, and once clicked we wait for it to be not visible also so we know the click has done something.
| WebElement we = resolve(); | ||
| // button may be obscured by say the "Save Apply" screen so we wait as Selenium will do a scroll but the CSS | ||
| // can take a while to update the layout \o/ | ||
| waitFor(we). |
There was a problem hiding this comment.
@aHenryJard this is the flake in the MCP tests.
I would prefer a method to actually check if something is clickable rather than trying repeatedly but I could not find anything.
| @@ -186,15 +195,18 @@ public void set(Object text) { | |||
| */ | |||
| public void selectDropdownMenu(Class type) { | |||
| click(); | |||
| findCaption(type,findDropDownMenuItem).click(); | |||
| elasticSleep(1000); | |||
the previous change (although it worked) probably worked by fluke. repeatidly getting the element in a waitFor did not change anything apart from taking a bit longer to do its thing (which solved the case but for the wrong reasons). the menu can be found regardless of if it is visible or not. so we just find it and then wait for it to become visible.
jtnord
changed the title
Control.click and Control.selectDropdownMenu
There was a problem hiding this comment.
Thank you !!
I just find all timeout/waiting times hard to read, if it's possible to use a shorter way like in Duration something similar to time.asSecond(1) time.asMillisecond(1000) it would be great. (because withTimeout() and pollingEvery() can be call with only one parameter Duration, I am not sure it was clear above)
| @@ -103,7 +105,14 @@ public void check(boolean state) { | |||
| * @see #clickAndWaitToBecomeStale(Duration) | |||
| */ | |||
| public void click() { | |||
| resolve().click(); | |||
| WebElement we = resolve(); | |||
| // button may be obscured by say the "Save Apply" screen so we wait as Selenium will do a scroll but the CSS | |||
There was a problem hiding this comment.
It's not only Selenium but
That might be contributing to weirdness...
There was a problem hiding this comment.
ahh thanks @amuniz I was wondering where the scrolling was happening as it didn;t seem to be Selenium :)
|
99 failures, 314 in the latest master build... so this is improving the situation! Go ahead! |
fixes various flakes.
click()was flaky when the WebElement had to be scrolled into view due to obsuring by the "Save" and "Apply" buttons (so we waitfor the click to happen).the dropDown selector was flaky and would sometimes not be visible - so also changed to using waits (and update the code that was sleeping to use wait to make the tests faster where possible)