How to use AddWebStorage class of org.openqa.selenium.remote.html5 package

It seems text is wrapped inside a label and not input. Try this

driver.findElement(By.xpath(".//label[text()[normalize-space() = 'Own Hotel']]"));

There is nice explanation about this xpath pattern here

String userAgent = (String) ((JavascriptExecutor) driver).executeScript("return navigator.userAgent;");

Instead of class name you can use a css selector. You don't mention the tagname for the class 'current time'. I am assuming it to be input, so your css selector work be,

WebElement element = driver.findElement(By.cssSelector("input[class='current time']"));
element.click();

Edit#1 Based on html provided,

Looking at the html in your comment, it seems you have quite a few options to find the webElement. Here are your options,

WebElement element = driver.findElement(By.cssSelector("a[class='current time']"));
element.click();

or this should work too,

WebElement element = driver.findElement(By.cssSelector("a.current.time"));
element.click();

You can also use linkText since the element is link. From the html you provided, the link text is 'url'

WebElement element = driver.findElement(By.linkText("url"));
element.click();

You can also use By.partialLinkText("partial link text here");

You can also use xpath as:

WebElement element = driver.findElement(By.xpath("//a[@class='current time']"));
element.click();

OR,

WebElement element = driver.findElement(By.xpath("//a[text() = 'url']"));
element.click();

They are not the same.

appDriver.findElement(By.xpath("//UIATableCell[2]")).findElement(By.xpath("//UIAStaticText[4]"));

Here, you are searching for //UIAStaticText[4] anywhere, at any level in the entire DOM tree:

When using xpath be aware that webdriver follows standard conventions: a search prefixed with "//" will search the entire document, not just the children of this current node. Use ".//" to limit your search to the children of this WebElement.

While //UIATableCell[2]/UIAStaticText[4] would search among the direct children of //UIATableCell[2] only.

There is an excellent article on medium.com by sahajamit

and i have tested the below code, it works perfectly fine with self-signed certificate https://badssl.com/

    ChromeOptions options = new ChromeOptions();
    options.setExperimentalOption("useAutomationExtension", false);
    options.addArguments("--headless", "--window-size=1920,1200","--ignore-certificate-errors");

    DesiredCapabilities crcapabilities = DesiredCapabilities.chrome();
    crcapabilities.setCapability(ChromeOptions.CAPABILITY, options);
    crcapabilities.setCapability(CapabilityType.ACCEPT_SSL_CERTS, true);
    crcapabilities.setCapability(CapabilityType.ACCEPT_INSECURE_CERTS, true);

    System.setProperty(ChromeDriverService.CHROME_DRIVER_LOG_PROPERTY, "C:\\temp\\chrome\\chromedriver.log");
    System.setProperty(ChromeDriverService.CHROME_DRIVER_EXE_PROPERTY, "C:\\temp\\chrome\\chromedriver.exe");

    ChromeDriverService service = null;
    try {
        service = new ChromeDriverService.Builder()
                .usingAnyFreePort()
                .withVerbose(true)
                .build();
        service.start();
    } catch (IOException e) {
        e.printStackTrace();
    }

    RemoteWebDriver driver = new RemoteWebDriver(service.getUrl(),crcapabilities);

    driver.get("https://self-signed.badssl.com/");
    System.out.println(driver.getPageSource());
    driver.quit();

software/framework versions

• Google Chrome Version 64.0.3282.186
• Google Chrome Driver Version 64.0.3282.186
• Selenium version 3.11.0

I ran across this same problem and could not find any solutions. Came up with a solution and posting it here, hope this helps someone with the same problem. I created a class to handle stale elements depending on their type, cssselector, id, etc and simply call it like I would any other page object.

public void StaleElementHandleByID (String elementID)
{
    int count = 0;
    boolean clicked = false;
    while (count < 4 && !clicked)
    {
        try 
        {
            WebElement yourSlipperyElement= driver.findElement(By.id(elementID));
            yourSlipperyElement.click(); 
            clicked = true;
        } 
        catch (StaleElementReferenceException e)
        {
            e.toString();
            System.out.println("Trying to recover from a stale element :" + e.getMessage());
            count = count+1;
        }
    }
}

I'd recommend only using this on elements you know cause problems for WebDriver.

Disabling "Instrumenting agent" worked for me. To do that you need to disable the async stack traces agent in "Settings | Build, Execution, Deployment | Debugger | Async Stack Traces"

You need to call ignoring with an exception to ignore while the WebDriver will wait.

FluentWait<WebDriver> fluentWait = new FluentWait<>(driver)
        .withTimeout(30, TimeUnit.SECONDS)
        .pollingEvery(200, TimeUnit.MILLISECONDS)
        .ignoring(NoSuchElementException.class);

See the documentation of FluentWait for more information. But beware that this condition is already implemented in ExpectedConditions, so you should use:

WebElement element = (new WebDriverWait(driver, 10))
   .until(ExpectedConditions.elementToBeClickable(By.id("someid")));

*Fewer versions of Selenium:

withTimeout(long, TimeUnit) has become withTimeout(Duration)
pollingEvery(long, TimeUnit) has become pollingEvery(Duration)

So the code will look as such:

FluentWait<WebDriver> fluentWait = new FluentWait<>(driver)
        .withTimeout(Duration.ofSeconds(30)
        .pollingEvery(Duration.ofMillis(200)
        .ignoring(NoSuchElementException.class);

A basic tutorial for waiting can be found here.

There a couple of things which you have to take care while dealing with InternetExplorer as follows :

As you mentioned There is a known issue with selenium documented in GitHub, these are not issues as such but is the combined set of Required Configuration while dealing with InternetExplorer. Without taking care of these settings InternetExplorer may not behave as per expectation. The following items are critical to demonstrate proper behavior of InternetExplorer v11 :

• Enhanced Protected Mode must be disabled for IE 10 and higher. This option is found in the Advanced tab of the Internet Options dialog.
• The browser Zoom Level must be set to 100% so that the native mouse events can be set to the correct coordinates.
• You have to set Change the size of text, apps, and other items to 100% in display settings.

• For IE 11, you will need to set a registry entry on the target computer so that the driver can maintain a connection to the instance of Internet Explorer it creates.

  For 32-bit Windows installations, the key you have to look in the registry is : 
  HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_BFCACHE
  
  For 64-bit Windows installations, the key is :
  HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_BFCACHE
  
  The FEATURE_BFCACHE subkey may or may not be present, and should be created if it is not present.
  

• Native Events : The advantage of using native events is that it does not rely on the JavaScript sandbox, and it ensures proper JavaScript event propagation within the browser. However, there are currently some issues with mouse events when the IE browser window does not have focus, and when attempting to hover over elements.

• Browser Focus : IE itself appears to not fully respect the Windows messages we send the IE browser window (WM_MOUSEDOWN and WM_MOUSEUP) if the window doesn't have the focus.

• You can find a detailed discussion on Native Events and Browser Focus here.

• Now, you have to configure all these parameters through DesiredCapabilities Class as follows :

  DesiredCapabilities cap = DesiredCapabilities.internetExplorer();
  cap.setCapability("ignoreProtectedModeSettings",1);
  cap.setCapability("IntroduceInstabilityByIgnoringProtectedModeSettings",true);
  cap.setCapability("nativeEvents",true);
  cap.setCapability("browserFocus",true);
  cap.setCapability("ignoreZoomSetting", true);
  cap.setCapability("requireWindowFocus","true");
  cap.setCapability("INTRODUCE_FLAKINESS_BY_IGNORING_SECURITY_DOMAINS", true);
  

• As per Best Programming practices Thread.sleep(1000); is a huge No as it degrades the Test Performance

• Now, as you are aware that the Browser Clients lags the WebDriver instance so we have to often sync up them. So before you collect the windowHandles you have to induce WebDriverWait as follows for which you can find a detailed discussion here :

  WebElement popup= driver.findElement(By.name("popup"));
  popup.click();
  new WebDriverWait(driver,5).until(ExpectedConditions.numberOfWindowsToBe(2));
  Set<String> windowHandles = driver.getWindowHandles();      
  System.out.println(windowHandles);
  

Update

I can see from your comments :

"Enable Enhanced Protected Mode" is unchecked in IE options. – Renjith Jan 9 at 7:26

Here is the exert from @JimEvans sensetional blog on Protected Mode settings and the Capabilities hack where @JimEvans nails the context in a clear and unambiguous term :

When the rewritten IE driver was first introduced, it was decided that it would enforce its required Protected Mode settings, and throw an exception if they were not properly set. Protected Mode settings, like almost all other settings of IE, are stored in the Windows registry, and are checked when the browser is instantiated. However, some misguided IT departments make it impossible for developers and testers to set even the most basic settings on their machines.

The driver needed a workaround for people who couldn't set those IE settings because their machine was overly locked down. That's what the capability setting is intended to be used for. It simply bypasses the registry check. Using the capability doesn't solve the underlying problem though. If a Protected Mode boundary is crossed, very unexpected behavior including hangs, element location not working, and clicks not being propagated, could result. To help warn people of this potential problem, the capability was given big scary-sounding names like INTRODUCE_FLAKINESS_BY_IGNORING_SECURITY_DOMAINS in Java and IntroduceInstabilityByIgnoringProtectedModeSettings in .NET. We really thought that telling the user that using this setting would introduce potential badness in their code would discourage its use, but it turned out not to be so.

If you are able to set the Protected Mode settings of IE, and you are still using the capability you are risking the stability of your code. Don't do it. Set the settings. It's not that hard.

Here is how you need to set the Protected Mode settings :

• Here is another discussion on Selenium IEServerDriver not finding new windows for IE9 where the solution was Turning on Compatibility Mode