How to use DefaultFieldDecorator class of org.openqa.selenium.support.pagefactory package

To close a single browser window:

driver.close();

To close all (parent+child) browser windows and end the whole session:

driver.quit();

I faced this problem quite recently.

All JS-based solutions didn't quite fit ICEFaces 2.x + Selenium 2.x/Webdriver combination I have.

What I did and what worked for me is the following:

In the corner of the screen, there's connection activity indicator.

            <ice:outputConnectionStatus id="connectStat"
                                        showPopupOnDisconnect="true"/>

In my Java unit test, I wait until its 'idle' image comes back again:

private void waitForAjax() throws InterruptedException {
    for (int second = 0;; second++) {
        if (second >= 60) fail("timeout");
        try { 
            if ("visibility: visible;".equals(
                selenium.getAttribute("top_right_form:connectStat:connection-idle@style"))) { 
                break;
            }
        } catch (Exception e) {

        }
        Thread.sleep(1000);
    }
}

You can disable rendering of this indicator in production build, if showing it at the page is unnecessary, or use empty 1x1 gifs as its images.

Works 100% (with popups, pushed messages etc.) and relieves you from the hell of specifying waitForElement(...) for each element separately.

Hope this helps someone.

The default of forkEvery is 0

According to the documentation forkEvery is

The maximum number of test classes to execute in a forked test process. The forked test process will be restarted when this limit is reached. The default value is 0 (no maximum).

So gradle (and probably junit) will fork by classes not tests within the class. It sounds like a few of the 87 test classes have long running tests or a large number of tests and they end up in one forked test process. I would consider setting forkEvery to 1. This will ensure that each test class is sent to a new fork. If there is still an issue you may need to find which test classes are taking the most time. Consider splitting these classes up into smaller groups of tests so the tests get spread over each jvm. If it is one test that takes forever consider redesigning it and possibly creating smaller tests from it.

I do not believe that gradle runs tests in batches. As a worker becomes available it takes a test class from the queue of remaining tests. You would really have to look at how JUnit works as I'm sure gradle is simply passing these configurations to JUnit.

You need to wait for Javascript and jQuery to finish loading. Execute Javascript to check if jQuery.active is 0 and document.readyState is complete, which means the JS and jQuery load is complete.

public boolean waitForJSandJQueryToLoad() {

    WebDriverWait wait = new WebDriverWait(driver, 30);

    // wait for jQuery to load
    ExpectedCondition<Boolean> jQueryLoad = new ExpectedCondition<Boolean>() {
      @Override
      public Boolean apply(WebDriver driver) {
        try {
          return ((Long)((JavascriptExecutor)getDriver()).executeScript("return jQuery.active") == 0);
        }
        catch (Exception e) {
          // no jQuery present
          return true;
        }
      }
    };

    // wait for Javascript to load
    ExpectedCondition<Boolean> jsLoad = new ExpectedCondition<Boolean>() {
      @Override
      public Boolean apply(WebDriver driver) {
        return ((JavascriptExecutor)getDriver()).executeScript("return document.readyState")
        .toString().equals("complete");
      }
    };

  return wait.until(jQueryLoad) && wait.until(jsLoad);
}

Scenario/Test steps:
1. Open a browser and navigate to TestURL
2. Scroll down some pixel and scroll up

For Scroll down:

WebDriver driver = new FirefoxDriver();
JavascriptExecutor jse = (JavascriptExecutor)driver;
jse.executeScript("window.scrollBy(0,250)");

OR, you can do as follows:

jse.executeScript("scroll(0, 250);");

For Scroll up:

jse.executeScript("window.scrollBy(0,-250)");
OR,
jse.executeScript("scroll(0, -250);");

Scroll to the bottom of the page:

Scenario/Test steps:
1. Open a browser and navigate to TestURL
2. Scroll to the bottom of the page

Way 1: By using JavaScriptExecutor

jse.executeScript("window.scrollTo(0, document.body.scrollHeight)");

Way 2: By pressing ctrl+end

driver.findElement(By.cssSelector("body")).sendKeys(Keys.CONTROL, Keys.END);

Way 3: By using Java Robot class

Robot robot = new Robot();
robot.keyPress(KeyEvent.VK_CONTROL);
robot.keyPress(KeyEvent.VK_END);
robot.keyRelease(KeyEvent.VK_END);
robot.keyRelease(KeyEvent.VK_CONTROL);

Check this post, I wrote code to get an absolute XPath.

public static String getAbsoluteXPath(WebElement element)
{
    return (String) ((JavascriptExecutor) driver).executeScript(
            "function absoluteXPath(element) {"+
                    "var comp, comps = [];"+
                    "var parent = null;"+
                    "var xpath = '';"+
                    "var getPos = function(element) {"+
                    "var position = 1, curNode;"+
                    "if (element.nodeType == Node.ATTRIBUTE_NODE) {"+
                    "return null;"+
                    "}"+
                    "for (curNode = element.previousSibling; curNode; curNode = curNode.previousSibling) {"+
                    "if (curNode.nodeName == element.nodeName) {"+
                    "++position;"+
                    "}"+
                    "}"+
                    "return position;"+
                    "};"+

                    "if (element instanceof Document) {"+
                    "return '/';"+
                    "}"+

                    "for (; element && !(element instanceof Document); element = element.nodeType == Node.ATTRIBUTE_NODE ? element.ownerElement : element.parentNode) {"+
                    "comp = comps[comps.length] = {};"+
                    "switch (element.nodeType) {"+
                    "case Node.TEXT_NODE:"+
                    "comp.name = 'text()';"+
                    "break;"+
                    "case Node.ATTRIBUTE_NODE:"+
                    "comp.name = '@' + element.nodeName;"+
                    "break;"+
                    "case Node.PROCESSING_INSTRUCTION_NODE:"+
                    "comp.name = 'processing-instruction()';"+
                    "break;"+
                    "case Node.COMMENT_NODE:"+
                    "comp.name = 'comment()';"+
                    "break;"+
                    "case Node.ELEMENT_NODE:"+
                    "comp.name = element.nodeName;"+
                    "break;"+
                    "}"+
                    "comp.position = getPos(element);"+
                    "}"+

                    "for (var i = comps.length - 1; i >= 0; i--) {"+
                    "comp = comps[i];"+
                    "xpath += '/' + comp.name.toLowerCase();"+
                    "if (comp.position !== null) {"+
                    "xpath += '[' + comp.position + ']';"+
                    "}"+
                    "}"+

                    "return xpath;"+

                    "} return absoluteXPath(arguments[0]);", element);
}

You shoudn't. JQuery selectors offer most of what CSS 2 and CSS 3 selectors do, plus something more, but you can probably live without it. If you know JQuery selectors, you already know CSS selectors.

Use CSS selectors where you can and use XPath expressions where it's not enough (they're stronger). I doubt you'll find many real usages where these two aren't enough (and then, the usual approach is to get what you can and iterate over the collection, filtering the results manually).

That said, you could possibly force WebDriver to accept JQuery selectors, too:

If you only want to support one or two browsers, the easiest way might be to write a simple addon to that browser which would inject JQuery to every page if it's not already present. You'd then force this addon to be used by the browser you're using.

If you want to support all of the browsers, that solution quickly becomes a burden and the best you could do is to write a decorator for WebDriver that would try to inject JQuery into the page before any findElements() and/or executeScript() call, if it's not already present.

See this question to get an idea about injecting JQuery.

After you've injected it, you can use it, again, only via JavaScript:

// earlier
if (driver instanceof JavascriptExecutor) {
    js = (JavascriptExecutor)driver;
} else {
    throw new IllegalStateException("This driver cannot run JavaScript.");
}

WebElement element = (WebElement)js.executeScript("$('div.account').get(0)");
// or
List<WebElement> elements = (List<WebElement>)js.executeScript("$('div.account').get()");

You can easily wrap those lines into a new By object, or a new findElement(String jQuerySelector) method for your decorated WebDriver, if you want, but that's up to your convenience and laziness, we got it working...

The best approach, I think, would be to create a new By implementation called ByJQuery. See this answer on how to make a ByJavaScript - it's a small step from there to reuse it, inject JQuery into the page and run the actual query.

class ByJQuery extends By implements Serializable {
    private final String query;

    public ByJQuery(String query) {
        checkNotNull(query, "Cannot find elements with a null JQuery expression.");
        this.query = query;
    }

    @Override
    public List<WebElement> findElements(SearchContext context) {
        WebDriver driver = getWebDriverFromSearchContext(context);

        if (!isJQueryInThisPage(driver)) {
            injectJQuery(driver);
        }

        return new ByJavaScript("return $(" + query + ")").findElements(context);
    }

    private static WebDriver getWebDriverFromSearchContext(SearchContext context) {
        if (context instanceof WebDriver) {
            return (WebDriver)context;
        }
        if (context instanceof WrapsDriver) {
            return ((WrapsDriver)context).getWrappedDriver();
        }
        throw new IllegalStateException("Can't access a WebDriver instance from the current search context.");
    }

    private static boolean isJQueryInThisPage(WebDriver driver) {
        // TODO Some JavaScript test for a JQuery object.
    }

    private static void injectJQuery(WebDriver driver) {
        // TODO Load JQuery from a file, inject it into the page via JS.
    }

    @Override
    public String toString() {
        return "By.jQuery: \"$(" + query + ")\"";
    }
}

The problem are not duplicate classes but the way generics are used. Here is a little MCVE replicating the situation in Appium's WebDriver class:

package de.scrum_master.stackoverflow;

public interface WebElement {}

package de.scrum_master.stackoverflow;

public interface WebDriver {
  <T extends WebElement> T findElement();
}

package de.scrum_master.stackoverflow;

public class Application {
  static WebDriver webDriver;

  static void myOverloadedMethod(String text) {}
  static void myOverloadedMethod(WebElement text) {}

  public static void main(String[] args) {
    // These 3 variants work
    myOverloadedMethod("test");
    myOverloadedMethod((WebElement) webDriver.findElement());
    WebElement webElement = webDriver.findElement();
    myOverloadedMethod(webElement);

    // This one does not work
    myOverloadedMethod(webDriver.findElement());
  }
}

Explanation: Due to type erasure doSomething's generic return type <T extends WebElement> evaluates to Object, so when trying to use that result for calling myOverloadedMethod(..) the compiler does not know which method to select.

Solution: You need to help by casting or explicitly declaring a type for a variable containing the method parameter.

P.S.: If you would modify the interface definition from interface WebDriver to interface WebDriver<T>, the compilation error would go away. But Appium's implementation does not do that, maybe because they want to stay as compatible(?) as possible to the original Selenium class. You have to ask them.

Update: Because the OP seems to have problems understanding my answer or to believe I did not try his sample code, which of course I used to reproduce and understand his problem:

package de.scrum_master.appium;

import org.openqa.selenium.By;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.WebElement;

public class Interactions {
  public static void touchWebElement(WebElement element, WebDriver driver) {}

  public static void touchWebElement(By by, WebDriver driver) {
    // Works
    WebElement webElement = driver.findElement(by);
    touchWebElement(webElement, driver);
    // Works
    touchWebElement((WebElement) driver.findElement(by), driver);
    // Ambiguous due to type erasure -> does not work
    touchWebElement(driver.findElement(by), driver);
  }
}

There is absolutely no need rename methods, re-package any classes or perform other types of Maven/Gradle stunts here.

Get all the window handles then iterate through them, switching webdriver to the new handle, then calling the close method. Obviously skip this for the original handle, then switch back to the remaining handle.

Something like;

    String originalHandle = driver.getWindowHandle();

    //Do something to open new tabs

    for(String handle : driver.getWindowHandles()) {
        if (!handle.equals(originalHandle)) {
            driver.switchTo().window(handle);
            driver.close();
        }
    }

    driver.switchTo().window(originalHandle);