Downloading wrong version of Chromedriver

[rysiaczek13]

Hi, I have one problem. When I'm trying to download the latest chromedriver:
npx webdriver-manager update --gecko=false --standalone=false --versions.chrome=85.0.4183.83
the version which is downloaded is 85.0.4183.38.
Do you have any idea, why it not download the correct version?
I/downloader - curl -oC:\TEST\Sources\Src\TestApps\node_modules\webdriver-manager\selenium/chromedriver_85.0.4183.83.zip https://chromedriver.storage.googleapis.com/85.0.4183.38/chromedriver_win32.zip

[Tyf0x]

Does anybody else have this issue? This broke our e2e tests on appveyor.

We're trying to use webdriver-manager update --versions.chrome $env:CHROME_VERSION --verbose --gecko false where CHROME_VERSION = 85.0.4183.87

webdriver-manager ends up downloading the version 85.0.4183.38 instead BUT saving it in a archive named 85.0.4183.87.

This then ends up breaking the tests because chromedriver cannot find chrome:

Which I assume was fixed in build .83:

[Shanson90]

We have this issue as well.

[lotz]

We are facing this issue too, as 85.0.4183.87 has some fixes to deal with closing alerts that we need. Unfortunately, webdriver-manager update uses the first version it can find for 85.0.4183 (which is .38), rather than the last version (.87). This is happening somewhere in the getSpecificChromeDriverVersion() function of chrome_xml.ts.

[Blackbaud-BobbyEarl]

We're seeing the same issue.

While debugging with @Blackbaud-TerryHelems, it seems this bug has been present for quite some based on #424 and #408. I believe it is only applicable on win32 systems using an x64 architecture where multiple versions exist for the same major version. The reason being line 103.

As we iterate through the (already filtered to the OS) list of possible versions, the code is able to catch the last matching version (with the last .digits removed) because those fall in to the successful else if branch as mac64 and linux64 exist. In windows; however, that second nested if fails since no versions contain win64 (so we're stuck with the first match).

I used the red -> green approach with the unit test I added in #473 (but forgot to do separate commits :-)) to show the current bug and potential fix.

[lotz]

Has anyone found a reliable way to work around this issue? I've tried downloading the correct version of ChromeDriver directly, and placing it in the correct node_modules sub-folder inside the protractor dependency, but it just gets overwritten later as Protractor itself updates it pretty late.

Some other options I can think of:

• Patch the affected chrome_xml.js file on the fly.
• Start a Selenium server and configure Protractor to use that.

[lotz]

I've worked around this by patching the chrome_xml.js file on the fly (using a super hacky approach): https://gist.github.com/lotz/d33f550d48dd125344d62321a8905d8b

To use, just add to your NPM postinstall script like so:

"postinstall": "node ./patch-webdriver-manager.js && webdriver-manager update"