webdriver-manager update refusing to dowload chromedriver_80.0.3987.106

[captaincaius]

Since going to v80 my e2e tests became unreliable, and the chromedriver changelog seems to imply lots of fixes in 80.0.3987.106. But webdriver-manager seems to refuse to get 106 at the moment.

[WEBDRIVER] [14:59:41] I/downloader - curl -o/home/buzzy/development/staffpond-mean/node_modules/webdriver-manager/selenium/chromedriver_80.0.3987.106.zip https://chromedriver.storage.googleapis.com/80.0.3987.16/chromedriver_
linux64.zip

Note the actual URL doesn't match.

This problem exists whether I let it choose the version itself or even if I use "webdriver-manager update --versions.chrome=80.0.3987.106".

On a related note, some docs say this should work but doesn't - --versions.chrome=80.0.3987

Thanks!

[jincheng-jason]

Same issue as I met

[Fuun347]

The usual fix for this would be to delete the node-modules + package-lock and then reinstalling them using npm i. Usually when I do that, webdriver-manager installs the correct version.

[captaincaius]

@Fuun347 thanks for the suggestion, but I've tried that and can confirm that it doesn't work in this case. The problem seems to be related to the logic webdriver-manager uses to detect which file to try to download.

[Fuun347]

What I can suggest, in that case, is just replacing the chromedriver file manually. It's not ideal, but it's a possible solution, if you're still looking for one.

[captaincaius]

I decided to look through the code and I actually think I found the problem...
https://github.com/angular/webdriver-manager/blob/legacy/lib/binaries/chrome_xml.ts#L146
it seems to consider those two versions as EQUAL, so whichever one comes later will win. I'll PR a proposed fix soon.

[Fuun347]

Well it's very weird, by all means, as mine updated to 106 without any issues.

[captaincaius]

just realized this is a duplicate of #424 - I didn't realize it cause it said "patch"... closing.