Selenium 4 support #452
Comments
tuxayo
changed the title
|
There's a selenium 4? Why? The driver vendors have barely implemented WC3 webdriver. |
|
Here is what I could find on the blog: |
|
Finally found the changelog! |
|
that's just version 4 of the ruby bindings. Why do I care about this? The standard is what matters to us. |
Indeed that wasn't the Selenium changelog. Though the blogposts and the tags show that there is an upcoming version 4 https://github.com/SeleniumHQ/selenium/tags
It seems it changed, I tried to run a test suite with selenium/standalone-firefox version 4.0.0-beta-1 instead of version 3 and the suite fails. Logs where I run the tests: Logs of the selenium container: |
|
Here is a simpler test script that works with version 3: logs with Selenium 4: |
|
Again, version of the software (in this case the selenium JAR) does not imply new standards. We can also not be shocked by alpha software not functioning. We also can't be shocked by the browser driver vendors ignoring the standard and doing what they want to instead. This is what appears to actually be happening: The Selenium JAR is just adding features. Which means i'll have to be compatible with it at some point, but as of yet there's not a great changelog I'm seeing, just links to their Javadoc. Which reminds me immediately why selenium is being abandoned in droves in favor of Playwright. What I'm actually doing about this all: In short I'm making a machine readable copy of the WC3 spec which we can then use to interface with the spec without actually having to change Selenium::Remote::Driver every time they get a wild hair. I use this exact same technique with the Playwright CPAN module, and it's automatically compatible with whatever version of the software you have installed. Unfortunately, neither the selenium JAR nor the browser vendors will ever ship a JSON definition of what methods they actually implement and what their inputs and outputs are, unlike Playwright does out of the box. This alone should make it astonishingly obvious why it's catching on much faster with implementers and maintainers. |
|
so as far as I can tell the big change is that they ripped out the JSONWire compat, which likely breaks an astonishing amount of the weird little hacks we've had to do over the years to make the browser drivers actually behave correctly Ultimately means I'm probably gonna have to refactor and overhaul everything again |
|
Thanks a lot for the analysis, it's more clear now. |
|
I'll try and have the re-factors done before chinese new year |
|
getting sessions and timeouts wrecked, and will probably never be fixed upstream, apparently Broken: get_alert_text elements: I also have to dismiss alerts() before go_back and go_forward(), yet more head-crammed-up-the-javascript-interpreter Every method that fails to execute here hangs for a minute or more before failing. amazing and this is just the results on geckodriver. I'm sure it's an absolute insane asylum on chrome |
|
looks like we can omit /wd/hub prefix finally, but that fixes nothing |
|
|
|
so yeah, as far as I can tell i'm executing things exactly as laid out by the spec, selenium 4 is just exploding |
|
looks like basically the same situation with chrome |
|
seems it's gagging on extra options. |
|
I can say with confidence people are going to absolutely love this new behavior of the selenium server straight-up hanging on any unrecognized input, lol |
|
and hanging for 30 seconds no less |
|
They had a lot of quirks with their input processing but I think I've got a 100% working client now Refactors will also mean lots of good new features like auto-spawn that isn't awful On schedule for chinese new year! |
|
OK, released the new backend to CPAN https://github.com/Troglodyne-Internet-Widgets/selenium-client-perl/tree/1.00 Now for all the compat work |
|
Thanks for the video, the updates and your great work to handle all those big changes :D |
tuxayo
changed the title
|
More in-depth discussion of things https://troglodyne.net/posts/1612566669 Documentation updates for S::R::D probably coming early next week |
|
Running Selenium Jar on my own, not related to this repo, was wondering how you fixed the java Timeouts in Selenium 4, specifically I'm trying to get window handles from Python and I'm getting the Java timeout @teodesian |
|
I suppose that they finally got out of beta? If so I probably will have to accelerate my plans to make Selenium::Client the backend for this module. |
|
I'm referring to the Beta versions actually, I was just wondering how you handled the timeout issues. |
|
I didn't handle them. I wrote a new module which should be much easier to maintain than this. Selenium::Client It's on CPAN, you can use it today. I plan to replace the backend of S::R::D with it at some point, but as I mentioned I'm busy with things that actually pay, unlike this. |
|
Ok I figured it out, took over a month. The solution was to remove the Content-Length header from the HTTP GET requests. I'm sure if anyone else has this bug, it could be a different header that needs to be removed, but thats the gist of it. I think the new client that Sel 4 is using, Netty, is more particular about the headers and times out for that reason. |
|
It is quite picky about headers, yes. It's much more of a stickler for the standard than before, and there are even more landmines waiting in various methods. I realized quickly it'd be a game of whack-a-mole if I didn't just replace RemoteConnection entirely, which is what lead to Selenium::Client. The good news is that I finally might have time to deal with this before too long. |
Hi :)
2 and 3 are supported and 4 alpha isn't, right?
The text was updated successfully, but these errors were encountered: