How to use DisplayAction class of org.openqa.selenium.interactions.internal package

PhantomJS uses different mechanism in setting capabilities

static ArrayList<String> cliArgsCap = new ArrayList<String>();
capabilities = DesiredCapabilities.phantomjs();
cliArgsCap.add("--web-security=false");
cliArgsCap.add("--ssl-protocol=any");
cliArgsCap.add("--ignore-ssl-errors=true");
capabilities.setCapability("takesScreenshot", true);
capabilities.setCapability(
    PhantomJSDriverService.PHANTOMJS_CLI_ARGS, cliArgsCap);
capabilities.setCapability(
    PhantomJSDriverService.PHANTOMJS_GHOSTDRIVER_CLI_ARGS,
        new String[] { "--logLevel=2" });
this.driver = new PhantomJSDriver(capabilities);

For more information about its command line, you could reference http://phantomjs.org/api/command-line.html

Did you try disabling the developer extensions with command line param?

Try with the following Selenium WebDriver java code:

System.setProperty("webdriver.chrome.driver", "D:\\chromedriver.exe");
ChromeOptions options = new ChromeOptions();
options.addArguments("--disable-extensions");
driver = new ChromeDriver(options);

TL;DR: Always use explicit wait. Forget that implicit wait exists.

---

Here is a quick rundown on the differences between explicit and implicit wait:

Explicit wait:

• documented and defined behaviour.
• runs in the local part of selenium (in the language of your code).
• works on any condition you can think of.
• returns either success or timeout error.
• can define absence of element as success condition.
• can customize delay between retries and exceptions to ignore.

Implicit wait:

• undocumented and practically undefined behaviour.
• runs in the remote part of selenium (the part controlling the browser).
• only works on find element(s) methods.
• returns either element found or (after timeout) not found.
• if checking for absence of element must always wait until timeout.
• cannot be customized other than global timeout.

---

Code examples with explanation. First implicit wait:

WebDriver driver = new FirefoxDriver();
driver.manage().timeouts().implicitlyWait(10, TimeUnit.SECONDS);
driver.get("http://somedomain/url_that_delays_loading");
WebElement myDynamicElement = driver.findElement(By.id("myDynamicElement"));

Now explicit wait:

WebDriver driver = new FirefoxDriver();
driver.get("http://somedomain/url_that_delays_loading");
WebDriverWait wait = new WebDriverWait(driver, 10);
WebElement myDynamicElement = wait.until(
  ExpectedConditions.presenceOfElementLocated(By.id("myDynamicElement")));

Both code examples do the same thing. Find a certain element and give up if not found after 10 seconds. The implicit wait can do only this. It can only try to find an element with a timeout. The strength of explicit wait is that it can wait for all kinds of conditions. Also customize timeout and ignore certain exceptions.

Example of possible conditions: elementToBeClickable, numberOfElementsToBeMoreThan or invisibilityOf. Here is a list of the built in expected conditions: https://seleniumhq.github.io/selenium/docs/api/java/org/openqa/selenium/support/ui/ExpectedConditions.html

More explanations:

The implicit wait timeout has effect only on findElement* methods. If set then all findElement* will "wait" for the set time before declaring that the element cannot be found.

How a findElement* will wait is not defined. It depends on browser or operating system or version of selenium. Possible implementations are:

• repeatedly try to find element until timeout. return as soon as element is found.
• try to find element. wait until timeout. try again.
• wait until timeout. try to find element.

This list is gathered from observations and reading bug reports and cursory reading of selenium source code.

---

My conclusion: Implicit wait is bad. The capabilities are limited. The behaviour is undocumented and implementation dependent.

Explicit wait can do everything implicit wait can and more. The only disadvantage of explicit wait is a bit more verbose code. But that verbosity makes the code explicit. And explicit is better that implicit. Right?

---

Further reading:

• Official documentation (does not really explain the problematic other than warning from mixing implicit and explicit wait).
• Answer on a related question from Jim Evans. Jim Evans is a maintainer of selenium. Summary: don't mix implicit and explicit wait.
• Two blog posts explaining implicit and explicit wait in great detail:
  • http://vnrtech.blogspot.de/2013/04/selenium-implicit-wait.html
  • http://vnrtech.blogspot.de/2013/04/selenium-explicit-wait.html
• Selected bugs about implicit and explicit wait in selenium:
  • http://code.google.com/p/selenium/issues/detail?id=2934
  • http://code.google.com/p/selenium/issues/detail?id=4471
  • http://code.google.com/p/selenium/issues/detail?id=7972
• Code
  • explicit wait
  • implicit wait
• What Happens When We Mix Implicit Wait And Explicit Wait
• How to create custom expected conditions in Selenium

Java 8 streams are an example of a fluent interface, and are intended to allow writing in a functional programming style. There is a lot of disagreement over what breaks the LoD and whether it even matters, but all that aside, the example in the documentation for Stream shows that you are using it as intended by the Java language designers.

If that isn't enough for your reviewer, note that the purpose of the Law of Demeter (aka the principle of least knowledge) is to keep programs loosely-coupled by minimizing the number of classes that a class directly communicates with. When A has a B and B has a C, and you want A to make C do something, you should have it tell B to get it done and let B worry about the details of how and when C is used.

In this case, every intermediate method on Stream is returning another instance of Stream, so you are still only coupled to the Stream class. I would not consider this a Law of Demeter violation.

I would also say that any class in a language should be considered coupled to the language's standard library. Therefore, any standard library objects should be exempt from the Law of Demeter, since you can't uncouple from them anyway. Otherwise, you wouldn't even be able to call get on a List that was returned by an object, or deal with a Set of Map.Entry from Map.entrySet(). This would also cover Stream, of course.

I was suggested to break the code to first stream to collect to list and run another stream operation to do match( in short break it down into multiple streams as needed).

Storing intermediate objects in local variables does not fix a Law of Demeter violation, you would still be accessing objects returned by other objects. It sounds like your reviewer is just blindly dot-counting.

Simply add to phantomJS's default desired capabilities, like so:

DesiredCapabilities desiredCapabilities = DesiredCapabilities.phantomjs();
desiredCapabilities.setCapability("phantomjs.cli.args", Collections.singletonList("--ignore-ssl-errors=yes"));

PhantomJSDriver driver = new PhantomJSDriver(desiredCapabilities);

You can perform any action on driver object, if it is throwing UnreachableBrowserException, then there is problem to communicate with the browser.

The most common causes for this exception are:

1. The provided server address to RemoteWebDriver is invalid, so the connection could not be established.
2. The browser has died mid-test.

And you can call the following method to verify the browser is closed or not.

public boolean isBrowserClosed(WebDriver driver)
{
    boolean isClosed = false;
    try {
        driver.getTitle();
    } catch(UnreachableBrowserException ubex) {
        isClosed = true;
    }

    return isClosed;
}

DesiredCapabilities would help you to change user agent.

You can achieve this by calling these methods:

• setBrowserName(java.lang.String browserName)
• setPlatform(Platform platform)
• setVersion(java.lang.String version)

Or

• static DesiredCapabilities chrome()
• static DesiredCapabilities firefox()
• static DesiredCapabilities iphone()
• ...

More here.

For anyone interested, I solved this in the following ways:

1) I was originally testing this on OSX with Firefox 17 and Selenium 2.28/29, but figured out it only works (at least for me) on Windows with Firefox 18 and Selenium 2.29

2) interacting with SVGs with the standard:

driver.findElement(By.xpath(YOUR XPATH)).click();

doesn't work. You need to use Actions.

3) to interact with SVG objects, the following XPath works:

"/*[name()='svg']/*[name()='SVG OBJECT']";

The SVG object being anything under the SVG element (e.g. circle, rect, text, etc).

An example of clicking an SVG object:

WebElement svgObject = driver.findElement(By.xpath(YOUR XPATH));
Actions builder = new Actions(driver);
builder.click(svgObject).build().perform();

Note: you need to call the path inside the click() function; using:

moveToElement(YOUR XPATH).click().build().perform();

doesn't work.

Just check for a single dialog-confirm class:

driver.findElement(By.className("dialog-confirm")).click();

Or, use a CSS Selector:

driver.findElement(By.cssSelector("button.dialog-confirm")).click()