Upgrade Selenium from 4.34 to 4.35

[basil]

#2118 causes new test failures consistently. This needs investigation.

[basil]

I took a quick look at this today, and I was only able to reproduce it locally some of the time (one out of every 10 or so runs), making it quite difficult to debug. I tried slowing down the container as described in jenkinsci/jenkins#10786 (comment), but that didn't help make the problem more reproducible, either.

The handful of times that I was able to reproduce this, I saw that in this stack trace we were attempting to click on an element that was (unexpectedly) out of view:

	at org.openqa.selenium.remote.RemoteWebElement.click(RemoteWebElement.java:76)
	at jdk.internal.reflect.GeneratedMethodAccessor25.invoke(Unknown Source)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:569)
	at org.openqa.selenium.support.decorators.WebDriverDecorator.call(WebDriverDecorator.java:315)
	at org.openqa.selenium.support.decorators.DefaultDecorated.call(DefaultDecorated.java:48)
	at org.openqa.selenium.support.decorators.WebDriverDecorator.lambda$createProxyFactory$3(WebDriverDecorator.java:405)
	at net.bytebuddy.renamed.java.lang.Object$ByteBuddy$SDvknOOF.click(Unknown Source)
	at org.jenkinsci.test.acceptance.po.Control.select(Control.java:250)
	at org.jenkinsci.test.acceptance.plugins.ssh_slaves.SshSlaveLauncher.selectCredentials(SshSlaveLauncher.java:139)
	at org.jenkinsci.test.acceptance.plugins.ssh_slaves.SshSlaveLauncher.waitForCredentialVisible(SshSlaveLauncher.java:129)
	at org.jenkinsci.test.acceptance.plugins.ssh_slaves.SshSlaveLauncher.pwdCredentials(SshSlaveLauncher.java:76)
	at plugins.SshSlavesPluginTest.customJavaPath(SshSlavesPluginTest.java:216)

This matches the recording, which is trying to click on the out-of-view element and failing. Scrolling the element into view is supposed to be done by Scroller, so I put a breakpoint there to see what was going wrong:

at org.jenkinsci.test.acceptance.selenium.Scroller.beforeClick(Scroller.java:95)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:569)
at org.openqa.selenium.support.events.EventFiringDecorator.callListenerMethod(EventFiringDecorator.java:355)
at org.openqa.selenium.support.events.EventFiringDecorator.fireBeforeEvents(EventFiringDecorator.java:253)
at org.openqa.selenium.support.events.EventFiringDecorator.lambda$beforeCall$0(EventFiringDecorator.java:189)
at org.openqa.selenium.support.events.EventFiringDecorator$$Lambda$508/0x00007f12ec36c000.accept(Unknown Source:-1)
at java.util.Arrays$ArrayList.forEach(Arrays.java:4204)
at org.openqa.selenium.support.events.EventFiringDecorator.beforeCall(EventFiringDecorator.java:189)
at org.openqa.selenium.support.decorators.DefaultDecorated.beforeCall(DefaultDecorated.java:43)
at org.openqa.selenium.support.decorators.WebDriverDecorator.lambda$createProxyFactory$3(WebDriverDecorator.java:404)
at org.openqa.selenium.support.decorators.WebDriverDecorator$$Lambda$506/0x00007f12ec3588b0.invoke(Unknown Source:-1)
at net.bytebuddy.renamed.java.lang.Object$ByteBuddy$GlHTHvL1.click(Unknown Source:-1)
at org.jenkinsci.test.acceptance.po.Control.select(Control.java:250)
at org.jenkinsci.test.acceptance.plugins.ssh_slaves.SshSlaveLauncher.selectCredentials(SshSlaveLauncher.java:139)
at org.jenkinsci.test.acceptance.plugins.ssh_slaves.SshSlaveLauncher.waitForCredentialVisible(SshSlaveLauncher.java:129)
at org.jenkinsci.test.acceptance.plugins.ssh_slaves.SshSlaveLauncher.pwdCredentials(SshSlaveLauncher.java:76)

However, after adding that breakpoint, the test started passing consistently, and I could (frustratingly) no longer reproduce the failure.

Additionally, in failing runs and in the failing CI build, I don't see any log statement that says "Scrolling failed", so the scroller at least thinks it is working, even though it didn't scroll the element into view.

I'm not sure what else I can do at this point, since I can't get the test to fail consistently on my system, and putting a breakpoint on the one portion of the code that seems relevant to the failure makes the test consistently start passing.

---

@jenkinsci/acceptance-test-harness-developers Does anyone have the time to look into this further? It would be great if someone could attempt to reproduce this locally and try to figure out why the scroller is sometimes failing to scroll the element into view (without logging any information when it does).

[basil]

While @jtnord does have a valid point that our Scroller implementation is overly complex/fragile and doesn't propagate errors properly, I don't think that is the root cause of what is going on here. I eventually simplified Scroller to #2140, which is as foolproof as it gets (delegating everything to the browser), but it didn't help resolve this issue.

#2139 sprinkles retries for ElementNotInteractableException all over the codebase, which is definitely not the solution we want. But that run does pass, which is interesting. When I was able to reproduce the problem, the page was scrolled to the top and calling the scroller didn't do anything. That indicates to me that we had somehow passed the wrong element to the scroller. Catching the exception, finding the element again, and passing it to the scroller seems to work. I'm not sure why the first time we find the element and try to scroll to it, scrolling fails (and we seem to be scrolled all the way to the top, which doesn't make sense?). This seems to be the case regardless of the scroller implementation, and is even the case with the clean scroller from #2140 (frustratingly).

I'm pinging @mawinter69 in case you have any ideas. I am out of ideas for the time being.