-
-
Notifications
You must be signed in to change notification settings - Fork 8.4k
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
[🚀 Feature]: Error when Selenium Manager used on unsupported architecture #11599
Comments
Turns out that Mac ARM architecture works just fine with AMD Selenium Manager, so that one isn't an issue. So, I'm going off of this list here: #11357 There are drivers available in various places for each of these architectures, but our current selenium manager binaries won't even run on them: If we checked in a 32 bit version of Selenium Manager for Windows & Linux, it should also work for 64 bit OS, right? |
Here are some rough numbers for geckodriver downloads:
So presumably we are currently supporting "only" ~90% of usage |
To clarify these figures a bit, the Selenium Manager Rust code already supports every platform in geckodriver (including win32, linux32, etc.). But it is true that the current compilation is only for win64, linux64, and mac64. So win32 and linux32 cannot be downloaded with Selenium Manager since the binary cannot be executed. But I have doubts ARM64 in Windows and Linux. Maybe the x64 binary can be executed in Windows and Linux (like in macOS). In that case, the |
I'm almost certain arm64 will need to be supported separately for Linux/Windows. So specifically for next release we need to add to the bindings checks with errors for the 4 above that can't be obtained automatically via Selenium right now. I'm *hoping we might be able to build & bundle 32 bit versions of Linux/Windows and that they will still work for 64 bit Linux/Windows. That would get us to > 95% at least, which is good enough until we figure out cross compilation. |
We had an informal chat a couple of days ago at SeleniumConf, where we realized that Windows 32 is going away and new versions are not coming in that flavor anymore. I tried to get a more "official" link, but this has the gist of it I would not want to support something that is slowly going away. We can add a FAQ in the docs showing what to do if you have a Windows 32 machine. What do you think? |
I don't think this is an issue any longer because our current binary supports win32 & win64, but...
At this point we only need to raise an error for "not x86 and not Apple" and Linux 32 bit |
What is missing to close this issue? |
We want the bindings to check for unsupported architectures and throw an error saying the architecture isn't supported. |
Shouldn't the process invoked by the bindings return something like that? We are already printing the error. |
We shouldn't try to send a command to an executable if we know it is the wrong executable, and we can be explicit about how we don't support that architecture so the user knows what is wrong. |
That is a good point. Right now with the amount of people we have around to work on this I would just delegate it to the OS and then print the message. But let's leave this open and see if someone can help. Low priority in my opinion. |
Alex says that the packaged binary works on ARM64 Windows as expected, which I think means the 3 binaries we have might be sufficient for everything. And at this point, I think if it doesn't work, we should wait to get feedback from users that it isn't working and what the error is. I was concerned the error a user got wouldn't be good enough, but if we can't even generate an error, this isn't necessary as a proactive measure. |
I am a firefox user on a 32 bit linux system. python 3.11 |
@ychaouche what was the error? |
Hello @titusfortner, Original code and traceback follows:
selenium-manager is ELF 64
I will read the given link and see how I can improve logging. |
Ok here's output with debug info from selenium
to my test code
|
Added a firefox_bin param,
but it says it's deprecated,
then same error message is displayed. |
I tried to use a service,
|
Oh... Sorry for being a little verbose, Issue solved. |
For the record, we've deprecated a bunch of things for 4.0, and are removing them for 4.10. So, setting Firefox Binary is:
|
Thanks for the headsup. |
setting path to the driver is a Service function. But, Selenium should be doing that for you automatically now. |
I guess it will search in the PATH,
|
I just upgraded to 4.11.0, which I think invokes Selenium Manager by default. I'm running on a Raspberry Pi (armv7l). What I am seeing is deployment of the selenium-manager linux binary and attempts to execute it, which naturally isn't going to work since I presume it is x64. In at least one execution run, the executable got left on disk as well... guessing I did something that bypassed the shutdown hook 😅 But since it is there, it makes for an easy execution test:
And naturally
Going to pass in a path to work around this, but just wanted to flag that invoking a |
@cml37 thanks for letting us know. Since I don't have a armv7l to test on, is there a condition that works to distinguish your architecture? |
Good question! Perhaps with Apache Commons, though I haven't tried it! https://commons.apache.org/proper/commons-lang/apidocs/org/apache/commons/lang3/ArchUtils.html |
I experimented with reproducing the same conditions that @cml37 commented. For that, I manually changed the binary contained in the Selenium 4.11.0 Java distribution (i.e., the file The problem is that the bindings always try to execute Selenium Manager, even when the driver is the PATH. After execution, Selenium Manager reports the driver to be used (on the PATH or download) on
I think the bindings (at least with Java, but perhaps it happens with the rest of the bindings) should do better and not error when the Selenium Manager binary cannot be executed. Otherwise, as it happens @cml37, Selenium cannot be executed in architectures like |
@bonigarcia as it ends up, you have to actually set the executable, see here: #11356 (comment) |
Yes, this issue was written with the idea that each of the bindings would throw the error rather than relying on Selenium manager binary. But "not compatible with the operating system" seems like a decent error? Not sure what it is in other bindings. We can reopen this if we want bindings to check for unsupported architectures and handle the error if we think that's better. But none of the other driver managers support these architectures, so seems reasonable that people would be managing them manually anyway. |
There are similar problems to @cml37's with the Ruby bindings on all aarch64 platforms because there are no platform specific gems published and https://rubygems.org/gems/selenium-webdriver/versions/4.11.0 includes only x64 binaries for each platform.
|
4.12 improves direct support for Mac aarch; the windows binary should work 32, 64 and aarch. As for Linux, Google doesn't release 32 bit drivers, and 32 bit Linux Firefox is 1% of geckodriver downloads. Users can add the driver path to a service class if selenium does not provide direct support. |
Thanks Titus for the comment above, it helped me to finally set everything up on my Raspberry Pi 4. For anyone landing on this thread after searching for the error code, here's what the service class looks like if you have to use it in your Python script:
If you need to set up geckodriver and Selenium on a Raspberry Pi, I wrote the following blog - https://nicolaslouge.com/post/how-to-set-up-selenium-python-geckodriver-raspberry-pi-arm-2023/ |
There's an alternate solution here: #12651 (comment) |
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Feature and motivation
Right now, Selenium Manager is called when a driver isn't specified or found on PATH. We only support 3 architectures, though. We should add code to explicitly check the user's architecture in preparation for additional additional architectures and throw an error until the architecture is actually supported.
This isn't as much of a problem while the Manager is in a "fall back" mode, but it can cause unexpected/confusing errors especially once we stop hiding them.
The text was updated successfully, but these errors were encountered: