Downloading wrong version of Chromedriver #472

Activity

1. Tyf0x commented on Aug 31, 2020

   

   Tyf0x

   on Aug 31, 2020

   More actions

   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:

   

   👍React with 👍4Reacted by Bobby Earl, Kurt Legerlotz, hoangnguyen-git and John
2. Shanson90 commented on Sep 1, 2020

   

   Shanson90

   on Sep 1, 2020

   More actions

   We have this issue as well.
3. lotz commented on Sep 1, 2020

   

   lotz

   on Sep 1, 2020

   Contributor

   More actions

   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.

   👍React with 👍1Reacted by Bobby Earl
4. Blackbaud-BobbyEarl commented on Sep 2, 2020

   

   Blackbaud-BobbyEarl

   on Sep 2, 2020

   Last edited by Blackbaud-BobbyEarl

   Contributor

   More actions

   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.

   👍React with 👍1Reacted by Kurt Legerlotz

   ❤️React with ❤️2Reacted by Tyf0x and Kurt Legerlotz
5. lotz commented on Sep 4, 2020

   

   lotz

   on Sep 4, 2020

   Contributor

   More actions

   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.
6. lotz commented on Sep 11, 2020

   

   lotz

   on Sep 11, 2020

   Last edited by lotz

   Contributor

   More actions

   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"
   

   ❤️React with ❤️1Reacted by Tyf0x
7. cnishina

   closed this as completedin #473on Jan 9, 2021