Skip to content
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

Chromedriver v91 regression: applying .getAttribute('value') on elements with tag name 'input' returns null instead of actual value #497

Open
karonov opened this issue Jun 8, 2021 · 12 comments

Comments

@karonov
Copy link

karonov commented Jun 8, 2021

First spotted on June 2nd.
chromedriver_91.0.4472.19
Downgraded back to chromedriver_90.0.4430.24 to get the value returned properly.

@Splaktar
Copy link
Member

Splaktar commented Jun 9, 2021

Related issue for Protractor: angular/protractor#5519

@Splaktar
Copy link
Member

Splaktar commented Jun 9, 2021

Also this looks like a duplicate of #496.

Related Chromium bug: https://bugs.chromium.org/p/chromium/issues/detail?id=1205107

@karonov
Copy link
Author

karonov commented Jun 9, 2021

Thanks for the reference @Splaktar !

@casicilian
Copy link

It looks like Chromium bug: https://bugs.chromium.org/p/chromium/issues/detail?id=1205107 been fixed but webdriver-manager is still installing the wrong version. Here is the curl command I am seeing. curl -o ...\node_modules\protractor\node_modules\webdriver-manager\selenium/chromedriver_91.0.4472.101.zip https://chromedriver.storage.googleapis.com/91.0.4472.19/chromedriver_win32.zip

So it looks like it is downloading 91.0.4472.19 but calling it chromedriver_91.0.4472.101

@lkedmi
Copy link

lkedmi commented Jun 14, 2021

Having the same issue, here's what we're seeing on CI

Running
./node_modules/.bin/webdriver-manager update --versions.chrome=91.0.4472.101

Getting
[07:02:41] I/downloader - curl -o/home/rof/src/github.com/.../node_modules/webdriver-manager/selenium/chromedriver_91.0.4472.101.zip https://chromedriver.storage.googleapis.com/91.0.4472.19/chromedriver_linux64.zip

@adgasi
Copy link

adgasi commented Jun 14, 2021

I am also facing the same issue for linux driver.

Running the following npm script

"update-driver": "webdriver-manager clean && webdriver-manager update --versions.chrome=91.0.4472.101 --gecko false --standalone false"

Getting
I/downloader - curl -o/home/[...]/common/temp/node_modules/.pnpm/[email protected]/node_modules/webdriver-manager/selenium/chromedriver_91.0.4472.101.zip https://chromedriver.storage.googleapis.com/91.0.4472.19/chromedriver_linux64.zip

Workaround:

  1. Download and unzip https://chromedriver.storage.googleapis.com/91.0.4472.101/chromedriver_linux64.zip
  2. Replace the existing driver in node_modules/webdriver-manager/selenium

This way I can run e2e's locally but of course it is still a blocker for CI, as it runs webdriver-manager update for each build.

@lkedmi
Copy link

lkedmi commented Jun 15, 2021

I am also facing the same issue for linux driver.

Running the following npm script

"update-driver": "webdriver-manager clean && webdriver-manager update --versions.chrome=91.0.4472.101 --gecko false --standalone false"

Getting
I/downloader - curl -o/home/[...]/common/temp/node_modules/.pnpm/[email protected]/node_modules/webdriver-manager/selenium/chromedriver_91.0.4472.101.zip https://chromedriver.storage.googleapis.com/91.0.4472.19/chromedriver_linux64.zip

Workaround:

  1. Download and unzip https://chromedriver.storage.googleapis.com/91.0.4472.101/chromedriver_linux64.zip
  2. Replace the existing driver in node_modules/webdriver-manager/selenium

This way I can run e2e's locally but of course it is still a blocker for CI, as it runs webdriver-manager update for each build.

I did something similar in CI (CodeShip) where I copy the chromedriver from the VM into node_modules/webdriver-manager/selenium by running the following commands (notice you'll need to replace [PROJECT_FOLDER]):

webdriver-manager update --versions.chrome=91.0.4472.101
webdriver-manager start --versions.chrome=91.0.4472.101
rm -f /home/rof/src/github.com/[PROJECT_FOLDER]/node_modules/webdriver-manager/selenium/chromedriver_91.0.4472.101*
curl -o /home/rof/src/github.com/[PROJECT_FOLDER]/node_modules/webdriver-manager/selenium/chromedriver_91.0.4472.101.zip https://chromedriver.storage.googleapis.com/91.0.4472.101/chromedriver_linux64.zip
cd /home/rof/src/github.com/[PROJECT_FOLDER]/node_modules/webdriver-manager/selenium
unzip chromedriver_91.0.4472.101.zip
mv chromedriver chromedriver_91.0.4472.101
chmod +x chromedriver_91.0.4472.101
cd -

@daddyman
Copy link

daddyman commented Jun 21, 2021

The problem is when webdriver is asked to install 91.0.4472.101 it actually installs 91.0.4472.19 of chromedriver.

The reason is when webdriver-manager is installing a specific version of Chromedriver - in this case 91.0.4472.101 - it downloads
the list of releases from Google (https://chromedriver.storage.googleapis.com/) which is XML and creates an array of the filenames.

The last part of this array looks like this:

[
 .....
  '88.0.4324.96/chromedriver_win32.zip',
  '89.0.4389.23/chromedriver_win32.zip',
  '90.0.4430.24/chromedriver_win32.zip',
  '91.0.4472.101/chromedriver_win32.zip',
  '91.0.4472.19/chromedriver_win32.zip',
  '92.0.4515.43/chromedriver_win32.zip'
]

Notice that in the data that 91.0.4472.101 is before 91.0.4472.19. It is in that order in the XML.

Webdriver-manager walks through the items looking for each that match the FIRST THREE parts of the version. In this case 91.0.4472. When it matches one it saves it as the one to use and keeps looking.

In this case it matches 2 entries .91.0.4472.101 and 91.0.4472.19. Because 19 (the older version) is in the array after 101 (the newer) version - then 19 is selected and downloaded.

I expect it is this way assuming that newer versions are always after older versions in the file. If webdriver checked that it was not replacing a newer version with an older version then this would not happen.

I made a local change to my installed webdriver and it then downloaded the correct version and the problem went away.

@daddyman
Copy link

To verify the problem, delete the selenium folder under webdriver-manager (node_modules/protractor/node_modules/webdriver-manager/selenium) and perform the webdriver-manager update.

In my case I see this line in the output:
[16:03:16] I/downloader - curl -oc:\dev\wf\prot\node_modules\protractor\node_modules\webdriver-manager\selenium/chromedriver_91.0.4472.101.zip https://chromedriver.storage.googleapis.com/91.0.4472.19/chromedriver_win32.zip

It is downloading 91.0.4472.19 but calling it 91.0.4472.101.

Either webdriver-manager needs to be smarter to not use an older version over a newer version (checking all 4 parts of the version) - or - the XML files returned from https://chromedriver.storage.googleapis.com/ needs to return the items in version order and not just alphabetical order.

@daddyman
Copy link

In the chromedriver ticket for this a member of the Chrome team said this:

The XML is automatically generated by the Google Cloud Storage (GCS) service, where all the chromedriver binaries are stored for download. It is a general file storage service, and not specific to chromedriver. Unfortunately I'm not aware of any way to override the ordering of files in the XML.

What webdriver-manager does has another potential issue. the GCS API can choose to truncate the list, and only return a partial list. See issue chromedriver:3494 for more details.

The recommended algorithm for selecting chromedriver version is given at https://chromedriver.chromium.org/downloads/version-selection. If webdriver-manager chooses not follow that algorithm, at least it needs to handle all variations of XML specified at https://cloud.google.com/storage/docs/xml-api/get-bucket-list.

From the document on downloading the correct version of chromedriver it would seem the best change would be to remove the xml logic and change to the algorithm in getSpecificChromeDriverVersion to follow the chromedriver documentation:

Here are the steps to select the version of ChromeDriver to download:

First, find out which version of Chrome you are using. Let's say you have Chrome 72.0.3626.81.

Take the Chrome version number, remove the last part, and append the result to URL "https://chromedriver.storage.googleapis.com/LATEST_RELEASE_". For example, with Chrome version 72.0.3626.81, you'd get a URL "https://chromedriver.storage.googleapis.com/LATEST_RELEASE_72.0.3626".

Use the URL created in the last step to retrieve a small file containing the version of ChromeDriver to use. For example, the above URL will get your a file containing "72.0.3626.69". (The actual number may change in the future, of course.)

Use the version number retrieved from the previous step to construct the URL to download ChromeDriver. With version 72.0.3626.69, the URL would be "https://chromedriver.storage.googleapis.com/index.html?path=72.0.3626.69/".

After the initial download, it is recommended that you occasionally go through the above process again to see if there are any bug fix releases.

@sschoorens
Copy link

Same here under linux too

[08:46:22] I/config_source - curl -o/home/[...]/node_modules/protractor/node_modules/webdriver-manager/selenium/chrome-response.xml https://chromedriver.storage.googleapis.com/
[08:46:22] I/downloader - curl -o/home/[...]/node_modules/protractor/node_modules/webdriver-manager/selenium/chromedriver_91.0.4472.101.zip https://chromedriver.storage.googleapis.com/91.0.4472.19/chromedriver_linux64.zip
[08:46:23] I/update - chromedriver: unzipping chromedriver_91.0.4472.101.zip

91.0.4472.19 still dowloaded for 91.0.4472.101

@sadym-chromium
Copy link

@andrevechina created a PR which should solve the issue: #498

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants