Sorry for not getting earlier at this, my pc had a complete meltdown, m2, and gpu both dead.
picking up a new one this afternoon.
thanks to @jdholtz :
This PR adds support for downloading Chromedriver versions 115+. This is necessary due to the Chromium team's change to Chromedriver's release process (see here).
If the version_main is 114 or older, the Chromedriver will still be downloaded using LATEST_RELEASE_{version}. If the version_main is specified and is 115+, the /latest-versions-per-milestone-with-downloads.json from the new JSON endpoint is used and the version is selected from the corresponding milestone. Last, if the version_main is not specified, the /last-known-good-versions-with-downloads.json endpoint is used to fetch the latest stable version.
In contrast with #1427, this PR uses the new JSON endpoints instead of reverting back to old versions if the LATEST_RELEASE endpoint isn't found (causing version discrepancy errors).
I also added compatibility for installing x86 and arm64 for Mac separately since the platform names changed for the new endpoints. However, I have only tested on Linux and Windows so it would be great if someone could test on Mac (x86 and ARM) It has been tested on Linux, Windows, and Mac with success. The Chromedriver doesn't work on ARM devices when downloading the ARM chromedriver, but it seems to work fine with the x64 version (possibly with Rosetta installed).
This also allows for users to download the Dev and Beta versions (currently 117 and 118) if they specify it using version_main.
* removed search paths for Chrome Canary and Chrome Beta from find_chrome_executable()
since chromedriver is always behind schedule so that means a driver for newer versions than current main could not be found and raises Exception.
* Changed/Fixed wrong binary version caused by patcher.
Due to multi-threading people and a mistake fromy my side,
the driver binary currently on disk was always used instead of getting new ones. even if you did not use multithreading.
so even outdated binaries where kept!
for multithreading people, it now only keeps the most recent binary and throws away others.
for normal people, you will get the binary you deserve ;)
* Added more descriptive exceptions when Chrome binary could not be found origin
no connection could be made to Chrome.
* some stuff i forgot
--------------------
https://youtu.be/kMjhrh_XDWk?t=48
--------------------
Big update! be careful as it -potentially- could break your code.
- rewritten the anti-detection mechanism
instead of removing and renaming variables, we just keep them, but prevent them from being injected in the first place
- rewritten the file naming, to prevent ending up with 1000 of {randomstring}_chromedriver.exe 's
instead it is just called undetected_chromedriver.exe
- cleanup
removed compat,v2 files and tests folder
after clicking a link
> added WebElement.children(self, tag=None, recursive=False)
to easily get/find child nodes
> added example.py where i can point people at
when asking silly questions
(no, its actually quite cool, everyone should see it)
> some refactoring
- use_subprocess now defaults to True
since many people do not understand python's multiprocessing and __name__ == '__main__'
- added option "no_sandbox" with a default value of True
since many people seem to run this as root (.......) , will run into errors since chrome does not run as root without using --no-
sandbox flag. the downside was that you would get another warning bar about "using unsecure command line flag".
uc's no_sandbox option also makes sure this warning get's supressed.
changed the way how patcher works (for those using multiple sessions/processes).
when not specifying a executable_path (the default, and recommended!), the filename
gets randomized to <somehex>_chromedriver[.exe]. this should fix the issue for multiprocessing
(although Chrome/driver itself has restrictions in this as well, see it using processhacker).
As i told before, webdriver is a purely io-based operation which only sends and pulls data. multiprocessing/threading isn't going to help much. You'd better use asyncio.)
find_chrome_executable:
added google-chrome-stable to the list, as some distro's have this name.
advanced_webelements: bool, optional, default: False
makes it easier to recognize elements like you know them from html/browser inspection, especially when working in an interactive environment
default webelement repr:
<selenium.webdriver.remote.webelement.WebElement (session="85ff0f671512fa535630e71ee951b1f2", element="6357cb55-92c3-4c0f-9416-b174f9c1b8c4")>
advanced webelement repr
<WebElement(<a class="mobile-show-inline-block mc-update-infos init-ok" href="#" id="main-cat-switcher-mobile">)>
note: when retrieving large amounts of elements ( example: find_elements_by_tag("*") ) and **print** them, it does take a little more time for all the repr's to fetch
Chrome() parameters
driver_executable_path=None
( = executable_path )
if you really need to specify your own chromedriver binary.
(don't log issues when you are not using the default. the downloading per session happens for a reason. remember this is a detection-focussed fork)
browser_executable_path=None
( = browser binary path )
to specify your browser in case you use exotic locations instead of the more default install folders
advanced_elements=False
if set to True, webelements get a nicer REPR showing. this is very convenient when working
interactively (like ipython for example).
<WebElement(<a class="mobile-show-inline-block mc-update-infos init-ok" href="#" id="main-cat-switcher-mobile">)>
instead of
<selenium.webdriver.remote.webelement.WebElement (session="85ff0f671512fa535630e71ee951b1f2", element="6357cb55-92c3-4c0f-9416-b174f9c1b8c4")>
changed the way how patcher works (for those using multiple sessions/processes).
when not specifying a executable_path (the default, and recommended!), the filename
gets randomized to <somehex>_chromedriver[.exe]. this should fix the issue for multiprocessing
(although Chrome/driver itself has restrictions in this as well, see it using processhacker).
As i told before, webdriver is a purely io-based operation which only sends and pulls data. multiprocessing/threading isn't going to help much. You'd better use asyncio.)
find_chrome_executable:
added google-chrome-stable to the list, as some distro's have this name.
advanced_webelements: bool, optional, default: False
makes it easier to recognize elements like you know them from html/browser inspection, especially when working in an interactive environment
default webelement repr:
<selenium.webdriver.remote.webelement.WebElement (session="85ff0f671512fa535630e71ee951b1f2", element="6357cb55-92c3-4c0f-9416-b174f9c1b8c4")>
advanced webelement repr
<WebElement(<a class="mobile-show-inline-block mc-update-infos init-ok" href="#" id="main-cat-switcher-mobile">)>
note: when retrieving large amounts of elements ( example: find_elements_by_tag("*") ) and **print** them, it does take a little more time for all the repr's to fetch
Chrome() parameters
driver_executable_path=None
( = executable_path )
if you really need to specify your own chromedriver binary.
(don't log issues when you are not using the default. the downloading per session happens for a reason. remember this is a detection-focussed fork)
browser_executable_path=None
( = browser binary path )
to specify your browser in case you use exotic locations instead of the more default install folders
advanced_elements=False
if set to True, webelements get a nicer REPR showing. this is very convenient when working
interactively (like ipython for example).
<WebElement(<a class="mobile-show-inline-block mc-update-infos init-ok" href="#" id="main-cat-switcher-mobile">)>
instead of
<selenium.webdriver.remote.webelement.WebElement (session="85ff0f671512fa535630e71ee951b1f2", element="6357cb55-92c3-4c0f-9416-b174f9c1b8c4")>
Leon
