Unnecessary stack trace from chrome selenium driver

I am using the SmartClientChromeDriver from the 6.0p from the build on 2016-07-05. When I call the waitForElementClickable method (see below), it sometimes dumps the exception stack (see below) to the console. However, the function continues to run until the condition is met and returns successfully. Most other methods just swallow exceptions like this if they are going to keep executing. This exception is cluttering up the output from my tests with exceptions that are not real issues and I cannot silence them because they appear to be internal to the driver code. Can we get these silenced?

driver.waitForElementClickable(ByScLocator.scLocator(locator), 30);

Exception in WebDriver.isElementClickable:org.openqa.selenium.StaleElementReferenceException: stale element reference: element is not attached to the page document
  
(Session info: chrome=51.0.2704.103)
  (Driver info: chromedriver=2.21.371459 (36d3d07f660ff2bc1bf28a75d1cdabed0983e7c4),platform=Windows NT 6.1 SP1 x86_64) (WARNING: The server did not provide any stacktrace information)
  Command duration or timeout: 1.10 seconds
  For documentation on this error, please visit: http://seleniumhq.org/exceptions/stale_element_reference.html
  Build info: version: '2.53.1', revision: 'a36b8b1', time: '2016-06-30 17:32:46'
  System info: host: 'PGREVER1', ip: '15.86.204.43', os.name: 'Windows 7', os.arch: 'amd64', os.version: '6.1', java.version: '1.8.0_74'
  Driver info: org.openqa.selenium.chrome.ChromeDriver
  Capabilities [{applicationCacheEnabled=false, rotatable=false, mobileEmulationEnabled=false, chrome={chromedriverVersion=2.21.371459 (36d3d07f660ff2bc1bf28a75d1cdabed0983e7c4), userDataDir=C:\Users\pgrever\AppData\Local\Temp\scoped_dir35008_5091}, takesHeapSnapshot=true, databaseEnabled=false, handlesAlerts=true, hasTouchScreen=false, version=51.0.2704.103, platform=XP, browserConnectionEnabled=false, nativeEvents=true, acceptSslCerts=true, locationContextEnabled=true, webStorageEnabled=true, browserName=chrome, takesScreenshot=true, javascriptEnabled=true, cssSelectorsEnabled=true}]
  Session ID: 56aaaecfd209eb82cb1caec895f59e42
  org.openqa.selenium.StaleElementReferenceException: stale element reference: element is not attached to the page document
  (Session info: chrome=51.0.2704.103)
  
(Driver info: chromedriver=2.21.371459 (36d3d07f660ff2bc1bf28a75d1cdabed0983e7c4),platform=Windows NT 6.1 SP1 x86_64) (WARNING: The server did not provide any stacktrace information)
  
Command duration or timeout: 1.10 seconds
  
For documentation on this error, please visit: http://seleniumhq.org/exceptions/stale_element_reference.html
  
Build info: version: '2.53.1', revision: 'a36b8b1', time: '2016-06-30 17:32:46'
  
System info: host: 'PGREVER1', ip: '15.86.204.43', os.name: 'Windows 7', os.arch: 'amd64', os.version: '6.1', java.version: '1.8.0_74'
  Driver info: org.openqa.selenium.chrome.ChromeDriver
  Capabilities [{applicationCacheEnabled=false, rotatable=false, mobileEmulationEnabled=false, chrome={chromedriverVersion=2.21.371459 (36d3d07f660ff2bc1bf28a75d1cdabed0983e7c4), userDataDir=C:\Users\pgrever\AppData\Local\Temp\scoped_dir35008_5091}, takesHeapSnapshot=true, databaseEnabled=false, handlesAlerts=true, hasTouchScreen=false, version=51.0.2704.103, platform=XP, browserConnectionEnabled=false, nativeEvents=true, acceptSslCerts=true, locationContextEnabled=true, webStorageEnabled=true, browserName=chrome, takesScreenshot=true, javascriptEnabled=true, cssSelectorsEnabled=true}]
  
Session ID: 56aaaecfd209eb82cb1caec895f59e42
   at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
   at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
   at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
   at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
   at org.openqa.selenium.remote.ErrorHandler.createThrowable(ErrorHandler.java:206)
   at org.openqa.selenium.remote.ErrorHandler.throwIfResponseFailed(ErrorHandler.java:158)
   at org.openqa.selenium.remote.RemoteWebDriver.execute(RemoteWebDriver.java:678)
   at org.openqa.selenium.remote.RemoteWebDriver.executeScript(RemoteWebDriver.java:577)
   at com.isomorphic.webdriver.SmartClientWebDriver.performJavascriptFunction(SmartClientWebDriver.java:385)
   at com.isomorphic.webdriver.SmartClientWebDriver.access$100(SmartClientWebDriver.java:65)
   at com.isomorphic.webdriver.SmartClientWebDriver$5.success(SmartClientWebDriver.java:331)
   at com.isomorphic.webdriver.SmartClientWebDriver$Waiter.waitFor(SmartClientWebDriver.java:369)
   at com.isomorphic.webdriver.SmartClientWebDriver.waitForJavascriptFunction(SmartClientWebDriver.java:333)
   at com.isomorphic.webdriver.SmartClientWebDriver.waitForElementClickable(SmartClientWebDriver.java:131)
   at com.hp.cp.pm.test.system.ui.selenium.Util.waitForElementClickable(Util.java:33)
   at com.hp.cp.pm.test.system.ui.selenium.LoadRework.executeTest(LoadRework.java:48)
   at com.hp.cp.pm.test.system.ui.selenium.LoadRework.run(LoadRework.java:22)
   at com.hp.cp.pm.test.system.ui.selenium.UiPerformanceTestRunner.run(UiPerformanceTestRunner.java:174)
   at com.hp.cp.pm.test.system.ui.selenium.UiPerformanceTestRunner.run(UiPerformanceTestRunner.java:78)
   at com.hp.cp.pm.test.system.ui.selenium.PerformanceTests.executeSpringContext(PerformanceTests.java:85)
   at com.hp.cp.pm.test.system.ui.selenium.PerformanceTests.main(PerformanceTests.java:19)

[Isomorphic]

An update on this: these exceptions seem to be coming from an internal race condition in the driver, and we don't have a way to avoid them being thrown. We are asking WebDriver for elements and then immediately using them with executeScript(), so there is no opportunity for them to become invalid except in the few moments during which WebDriver interacts with the browser to set up script execution.

The fact that you are routinely receiving these may indicate some kind of latency problem between the process where your WebDriver code is executing and the process running the browser; reducing that latency would likely decrease exceptions like this and increase test execution speed.

As far as suppressing these warnings, we're reluctant to do so, as this could suppress warnings you actually do want to see. In fact, arguably the warnings you are asking about are warnings you do want to see, as they may indicate a latency problem in your test environment.

I don't think it is latency because the problem seems to be caused by executing the tests as fast as possible. It seems to happen when we wait for a dialog button to become available to click (we immediately hit "OK" in the dialog as soon as we can detect that the button is clickable). However we bring this dialog up, destroy it and then bring it up again. It seems that this code is executing too quickly and is picking up the old element from the previous incarnation of the dialog and that is what is causing the exceptions. It is also interesting that once we've destroyed this dialog, we can try to find the element and call isDisplayed on it (which returns false), but if we use the SmartClient driver waitForElementPresent, it immediately returns true. I'll try putting in a sleep to see if waiting a little longer for the new instance of the dialog to be set up will eliminate the issue.

It does still seem strange to me that you would swallow the exception (so there is no way for me to tell that it happened programmatically) but you dump the exception the console (again with no way for me to control the output from my test).

It also seems strange that the SmartClient web driver functions don't integrate more tightly with the standard WebDriver waiting model. For example, with the standard model you would use WebDriverWait. In this case, it would normally exception for a StaleElement exception which I could catch and then choose how to handle. If I want it ignored, I can add an "ignore" clause to the WebDriverWait (as well as controlling other things like the polling frequency). The SmartClientWebDriver methods don't provide this same flexibility. If there were primitive methods provided (like isPresent, isClickable, isGridDone, etc.), then these could be used with the standard WebDriverWait functionality (giving more control and options, which in turn would give me control over how to handle the StaleElement exception in my case).

[Isomorphic]

We've made some adjustments to WebDriver's logic in SGWT 6.0p/SC 11.0p and newer which may reduce the frequency of the unwanted exceptions you're seeing in the log. The changes will be in the nightly builds dated 7-27-2016 and beyond.

Thanks you!