17

Until my google Chrome wasn't updated to version 78 my code worked fine. I also updated the chromedriver to version 78.0.3904.70. So I am not able anymore to find WebElement with id='plugin' using Selenium WebDriver and Java:

<html>
<div id="content">
<embed id="plugin" type="application/x-google-chrome-pdf" src="http://??????????/offer_printed.php?printable=yes&amp;reanudar=&amp;>
</div>
</html>

Other than that part my tests are working fine. I never had a similar issue before. I also tried to find WebElement id='content' but I am receiving the same error.

WebDriverWait wait = new WebDriverWait (driver, 90);
WebElement scrollvalid = wait.until(ExpectedConditions.visibilityOfElementLocated(By.id("plugin")));

scrollvalid.sendKeys(Keys.PAGE_DOWN);                       scrollvalid.sendKeys(Keys.PAGE_DOWN);

My automation script should find the PDF element and scroll the page down. Instead, I am receiving this error: org.openqa.selenium.TimeoutException: Timed out after 90 seconds waiting for visibility of element located by By.id: plugin

Is anybody facing a similar issue? Thanks in advance.

Krishnan Mahadevan
  • 14,121
  • 6
  • 34
  • 66
Mix
  • 173
  • 1
  • 1
  • 7
  • Today I deleted Google Chrome version 78 and installed version 76 and my automation test works again. Everything works perfectly. I hope that this issue with version 78 will be fixed. So I was using chromedriver (version 78) and in my .pom file I have following dependency: org.seleniumhq.selenium selenium-chrome-driver 3.141.59 – Mix Oct 30 '19 at 08:58
  • I am having the same issue. Code that worked before, now fails because the web driver fails to locate whatever web element I am trying to locate. Implicit and explicit waits fail the same. What I have not been able to pinpoint is the type of elements it is having problems with or if it is just components located inside an iframe. As a workaround, I have been adding `Thread.sleep` in places where I had implicit or explicit waits before this update. – hfontanez Nov 12 '19 at 22:55
  • Chrome 78 with chromedriver 77 works for me. – Yun Dec 09 '19 at 10:07

9 Answers9

5

I've run into the same issue.

Apparently Chrome automatically updates itself. Yesterday (Oct 29 '19) My ChromeDriver started complaining that it was not compatible with Chrome 78. I updated the driver to the 78 version. I started to get random org.openqa.selenium.NoSuchElementException exceptions when trying to find elements that I confirmed were there. The findElement[s] also work when I used breakpoints. I also tried implicit waits, with only limited success.

I tried zsbappa's ChromeOption solution but no joy.

Google makes it hard to get old versions of Chrome, but I found version 76 at https://www.neowin.net/news/google-chrome-76-offline-installer/. Beware, the online installer installs the latest version. I reverted to the driver for 76 and all is good. All my Selenium tests are working again.

My conclusion is that the Chrome 78 and it's associated driver has a race condition where Selenium attempts to interrogate the web page before it's complete.

wdtj
  • 4,554
  • 3
  • 17
  • 20
  • I have opened Issue 3198 with the ChromeDriver developers. – wdtj Oct 30 '19 at 17:16
  • 1
    I received the following response to my issue: Thank you for reporting this issue. As of version 77, Chromedriver does not wait for frames or iframes to load when navigating to a new page, or switching windows. This does introduce the need for code wait for resources to be available. Most bindings have an explicit wait as well as the implicit wait settings. Search for WebDriverWait in the Selenium documentation for more information. – wdtj Nov 04 '19 at 14:34
  • But we are using explicit waits and that doesn't help. It does help for changing iframes but the HTML tags are not visible anymore for embedded pdf. – Mix Nov 05 '19 at 16:44
  • I opened a new issue on the chromedriver group: https://bugs.chromium.org/p/chromedriver/issues/detail?id=3211 – Mix Nov 05 '19 at 17:01
  • You can use Chromium for tests, it's a basic version of Chrome without the Google services, it won't update itself and it works fine with Chromedriver: https://www.chromium.org/getting-involved/download-chromium – Blaise Dec 10 '19 at 09:43
3

We have faced a similar issue with Chrome 78.0.3904.7, Chromedriver 77/78, Python Selenium 3.141.0.

In our automated Python Selenium tests, we've seen multiple failures where it appears that clicks on elements have not occurred. Even stranger, it appears that the element has become active (as if it were about to be clicked) but the the actual click event never occurred. As a result, page switches etc do not occur resulting in various downstream failures.

By a process of trail and error, we found that using the standard .click() function is now not reliable:

webdriver_element.click()

But using Action Chains does appears to be reliable:

ActionChains(context.browser).click(webdriver_element).perform()

It's not clear why this is the case. The failures began as soon as we upgraded to Chrome 78.0.3904.7. We're using Chromedriver 77.0.3865.90 but the same tests pass reliably on Chrome 77.x versions therefore it appears something is wrong or has changed in Chrome 78.

1

By adding the following argument I have solved my problem.

   ChromeOptions options = new ChromeOptions();
    options.addArguments("--disable-gpu");
    options.addArguments("--disable-extensions");
    options.setExperimentalOption("useAutomationExtension", false);
    options.addArguments("--window-size=1920,1080");
    options.merge(seleniumCapabilities);
    driver = new ChromeDriver(options);
Zakaria Shahed
  • 2,589
  • 6
  • 23
  • 52
  • Hi @zsbappa! Thank you for your reply. However, this doesn't solve my problem. The problem is that chromedriver (version 78) can not find any web element in embedded pdf. This functionality worked fine until Google chrome wasn't updated to version 78. P.S. I am NOT running my tests in headless mode – Mix Oct 29 '19 at 12:07
  • This doesn't solve the problem. Most likely, you are running scenarios where the web element is not located inside an iframe. – hfontanez Nov 13 '19 at 16:54
1

I have faced the same issue when trying to access a tab inside an iframe , it used to work fine on version 76. Now that has updated itself to 78, it's failing. Have tried waits , implicit waits , sleep , locate the elements using xpath, CSS, id , switch context , scroll until view , etc.., with no luck. I'm using windows 10 , 1809. I don't know if this is happening in other OS.

Here is the question I raised :

Problem using chromedriver 78.0.3904.70 locators

DavidRYV
  • 45
  • 7
1

I confirmed yesterday that this issue appears to manifest itself only when an element is contained in an iframe. In those cases, the iframe is located fine. However, attempting to locate a web element using the driver or web driver wait objects will result in a NoSuchElement or TimeoutException respectively.

I provided the chromedriver team a verbose chrome driver log and they are working on it.

UPDATE: From chromedriver issue 3223

The logs show that the final executionContextCreated for the frame doesn't complete until after the FindElement returns null. Starting in version 77, ChromeDriver stopped waiting for all frames to load before continuing navigation. Unfortunately, that change prevented a wait for the current frame to load. 3164 will all a wait for the current frame to load; this should prevent FindElement from searching until after the frame has Stopped loading and the executionContext is created.

Basically, this bug was introduced in v.77. Many of us just noticed this problem because we upgraded from v.76 to .v78. Word is that they are targeting a fix for .v80 (not v. 79). As a workaround, I am using Thread.sleep between the time I switch to the iframe and when I attempt to locate the component. This workaround works fine. In fact, you can verify this on your own by simply running your application in DEBUG mode. When you pause execution (by using a breakpoint), you'll notice that your original code (without the sleep) works fine.

hfontanez
  • 5,774
  • 2
  • 25
  • 37
0

For example: You can try using this keywords!.

1. implicit_wait=10
2. Sleep  10
  • Hi @Narasimhamurthy G N, thank you for your answer. The Explicit Wait is not a problem, I am using Explicit Waits all across my tests and I am not facing a similar problem. The problem is that chromedriver (version 78) can not find any web element in embedded pdf. – Mix Oct 29 '19 at 13:39
  • For me some test cases i have also faced same issue for that i used "geckodriver" (Firefox). – Narasimhamurthy G N Oct 30 '19 at 07:24
  • otherwise use different selenium library locator keyword to find WebElement. – Narasimhamurthy G N Oct 30 '19 at 07:27
  • Unfortunately, it is recommended that the users of our web application use Chrome or Internet Explorer, Firefox is not recommended for some reason. That is why I can not use Firefox to automate the tests. I tried to use all possible ways to find any web element on pdf using selenium but it doesn't work. I also tried using different dependencieds and chromedrivers and nothing works. – Mix Oct 30 '19 at 09:25
0

It turned out to be a problem with the Google Chrome, not chromedriver: https://bugs.chromium.org/p/chromedriver/issues/detail?id=3211

Mix
  • 173
  • 1
  • 1
  • 7
0

I had the same issue.

After auto-updating Chrome with version 78.0, my automated test scripts were failing. So I updated chromedriver to the 78 version, but driver was still not able to find any web element. After that I tried with multiple versions of chromedriver and finally my issue is resolved with chromedriver version 2.44.

This version can be found at https://chromedriver.storage.googleapis.com/index.html?path=2.44/

usernumber
  • 1,958
  • 1
  • 21
  • 58
Sagar Bhavsar
  • 278
  • 3
  • 8
-1

You can Nuget package manager, delete Chrome drive and search for chrome, download the new version selenium.web.driver.ChromeDriver >> for jsaKamoto

there you find chrome version 78.

Thiago
  • 1
  • Thanks for the response, but it does not really answer the problem of NoSuchElement exceptions in chrome version 78. – wdtj Oct 30 '19 at 15:47