How to use getData method of org.openqa.selenium.remote.http.FormEncodedData class

It looks like not frame. If it is frame then you can insect those buttons. So are you able to inspect those buttons? if not then it is alert which is cased by javascript. Use switch to alert here

   Alert alert = driver.switchTo().alert();
    alert.accept(); // for OK

Thank You, Murali

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.

You could essentially turn the body of the loop to a lambda expression and collect the the results

List<String> testing = 
    measureKeys.stream()
               .map(e -> element.getText().split("\\(")[0])
               .collect(Collectors.toList());

If you use Python to lauch your chromedriver instance you may consider this gist :

https://gist.github.com/BuhtigithuB/11df8cf8d03bb236985156de204fe7b4

And my answer here :

WebDriver: How to specify preferred languages for Chrome

UPDATE

Since you specify JAVA here a gist that suppose to work for JAVA :

https://gist.github.com/c089/a5cbb834f9b54004de9b

Please recheck if the following code is really present:

ng-if="new_user && old_email"

Because initially it was:

ng-if="new_user && old_email"

I.e. it looks like Selenium replaces && symbols by

&&

in ng-if and it's the root of the issue: Angular can't parse "non JS" code (or interprets it incorrectly)

P.S. The same is with the following code:

ng-if="existing_user && old_email"

i.e.

&&

is present instead of && in ng-if too.

The visibilityOfElmementLocated checks to see if the element is present and also visible. To check visibility it makes sure the element has a height and width greater than 0.

The presenceOfElementLocated just checks the dom to see if it can locate an element no matter its visibility.

Source: https://selenium.googlecode.com/git/docs/api/java/org/openqa/selenium/support/ui/ExpectedConditions.html#visibilityOf-org.openqa.selenium.WebElement-

visibilityOf public static ExpectedCondition visibilityOf(WebElement element) An expectation for checking that an element, known to be present on the DOM of a page, is visible. Visibility means that the element is not only displayed but also has a height and width that is greater than 0. Parameters:

I have tried it using Firefox.You need to guide Firefox so that it executes in the Xvfb.

You can try the following:

String Xport = System.getProperty("lmportal.xvfb.id", ":1");

final File firefoxPath = new File(System.getProperty("lmportal.deploy.firefox.path", "/usr/bin/firefox"));

FirefoxBinary firefoxBinary = new FirefoxBinary(firefoxPath);

firefoxBinary.setEnvironmentProperty("DISPLAY", Xport);

You seem to be missing the closing round and square brackets:

Change this:

//body[contains(@class, 'is-mobile'

Into this:

//body[contains(@class, 'is-mobile')]

As a side note, take into account that this code has another slightly hidden issue and it is that you will match things that you do not want to match such as this class attribute: login-page not-is-mobile.

There is no way to simply match that as you would using the CSS3 selector [class~="is-mobile"]. However, you can come around this by doing this:

//body[contains(concat(' ', @class, ' '), ' is-mobile ')]

All those spaces are there to make sure you will match only something between spaces and that it also matches even if it is at the beginning or end of the class attribute.

It is ugly indeed but that is the XPath way of doing this.

Selenium's Java client tools and libraries uses reflection to access parts of the JDK that are meant for internal use only. This illegal reflective access will be disabled in a future release of the JDK. While using JDK 9, it is permitted by default and a warning is issued as follows:

WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by org.openqa.selenium.os.ProcessUtils 
WARNING: Please consider reporting this to the maintainers of org.openqa.selenium.os.ProcessUtils
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release

As per the article Understanding Runtime Access Warnings by default, a maximum of one warning about reflective access is issued in the lifetime of the process started by the java launcher. The exact timing of the warning depends on the behavior of tools and libraries performing reflective–access operations. The warning may appear early in the lifetime of the process, or a long time after startup.

You can disable the warning message on a library-by-library basis by using the --add-opens command line flag. For example, you can start Selenium in the following way:

>java --add-opens java.base/sun.nio.ch=ALL-UNNAMED --add-opens java.base/java.io=ALL-UNNAMED -jar selenium-server-standalone-3.14.0.jar

Relaxing strong encapsulation

To help us in the migration to Java 9, an implementation was needed to relax the strong encapsulation of the modules that that would have addressed the following:

• An implementation which may provide some means to invoke its run-time system with one or more packages of one or more of its modules open to code in all unnamed modules, i.e., to code on the class path. If the run-time system is invoked in this way, and if by doing so some invocations of the reflection APIs succeed where otherwise they would have failed, then the first such invocation must cause a warning to be issued on the standard error stream. Later such invocations may also cause warnings to be issued.

• An implementation which may by default, open one or more packages of one or more of its modules to code in all unnamed modules at run time. If it does so then it must issue warnings as described in the previous paragraph. If it does so then it must, further, provide a means to invoke its run-time system without opening any packages of any of its modules. (The Reference Implementation’s run-time system behaves this way by default, and because this is the default it can also be invoked without opening any of its packages via the command-line option --illegal-access=deny.)

Future revisions of this specification are expected to mandate that all of an implementation’s modules be strongly encapsulated by default and, eventually, to disallow the above-described relaxation.

JEP 261: Module System

With the arrival of JEP 261: Module System the strong encapsulation of some of the JDK's packages is relaxed by default, as permitted by the Java SE 9 Platform Specification. This relaxation is controlled at run time by a new launcher option --illegal-access, which works as follows:

• --illegal-access=permit: This option opens each package in each module in the run-time image to code in all unnamed modules, i.e., to code on the class path, if that package existed in JDK 8. This enables both static access, i.e., by compiled bytecode, and deep reflective access, via the platform's various reflection APIs.
• --illegal-access=warn: This option is identical to permit except that a warning message is issued for each illegal reflective-access operation.
• --illegal-access=debug: This option is identical to warn except both a warning message and a stack trace are issued for each illegal reflective-access operation.
• --illegal-access=deny: This option disables all illegal-access operations except for those enabled by other command-line options, e.g., --add-opens.

Note: This mode is the default in JDK 9. It will be phased out in a future release and, eventually, removed.

Solution

A quick fix solution would be to revert back to the latest version of Java 8