How to use getAriaRole method of org.openqa.selenium.Interface WebElement class

It is better to mark the webdriver as a singleton for the entire framework. I had been currently using this pattern and it works fine.
Note: Care should be taken when dealing with parallel execution.

@CodeEnthusiastic For example take a class GeneralLibrary, in that create a WebDriver.

Extend the classes in Page Object Model with GeneralLibrary as super class

Try setting an implicit wait of maybe 10 seconds.

gmail.manage().timeouts().implicitlyWait(10, TimeUnit.SECONDS);

Or set an explicit wait. An explicit waits is code you define to wait for a certain condition to occur before proceeding further in the code. In your case, it is the visibility of the password input field. (Thanks to ainlolcat's comment)

WebDriverWait wait = new WebDriverWait(gmail, 10);
WebElement element = wait.until(
    ExpectedConditions.visibilityOfElementLocated(By.id("Passwd")));
gmail.findElement(By.id("Passwd")).sendKeys("xyz");

Explanation: The reason selenium can't find the element is because the id of the password input field is initially Passwd-hidden. After you click on the "Next" button, Google first verifies the email address entered and then shows the password input field (by changing the id from Passwd-hidden to Passwd). So, when the password field is still hidden (i.e. Google is still verifying the email id), your webdriver starts searching for the password input field with id Passwd which is still hidden. And hence, an exception is thrown.

The easiest way to exit the page load wait early is to set the page load timeout. When the timeout expires, you can catch the TimeoutException and proceed with the next step of your test. The code to invoke this would look something like the following:

// Set the page load timeout to 10 seconds.
driver.manage().timeouts().pageLoadTimeout(10, TimeUnit.SECONDS);

try {
  driver.get("http://url/to/my/slow/loading/page");
} catch (TimeoutException e) {
  // Ignore the exception.
}

// Proceed with your next step here.

Note that you may have to use a WebDriverWait or similar to ensure the element you're interested in is present on the page.

There is apparently a new feature in Selenium as of May this year -- the @FindAll annotation that does exactly what I need;

http://selenium.10932.n7.nabble.com/Pull-Request-62-Add-a-FindAll-annotation-to-the-Java-Page-Factory-td24814.html

You should use WebDriverWait with some expected condition. For example,

WebDriverWait wait = new WebDriverWait(driver, 5); // sets timeout to 5 seconds
wait.until(...); // Use ExpectedCondition to set the condition you need to check for (i.e. element to be clickable, frame to be visible, etc.)
// Do your thing.

The until method will return an object type relative to the function passed. For example, until(ExpectedConditions.elementToBeClickable(...)); will return a WebElement object you can use to exert an action on (like clicking on it).

Lastly, you should wrap those lines in a try/catch and handle the TimeoutException the wait method will throw if the condition never arises.

To summarize, structurally, your code should look something like this:

// instantiate the WebDriver
...
int timeoutMax = 2; // The maximum number of seconds you wish to wait before timing out (let's assume 2 seconds is reasonable for your case)
try {
    By checkboxLocator = By.id("checkboxID"); // Locate element by some criteria (id, css, xpath). Using by ID for illustration purposes only
    By buttonLocator = By.id("buttonID"); // same as above
    By popupLocator = By.id("frameid"); // same as above
    WebDriverWait wait = new WebDriverWait(driver, timeoutMax);
    wait.until(ExpectedConditions.frameToBeAvailableAndSwitchToIt(popupLocator)); // assuming it is an iframe

    // The next lines will not be executed if the "Don't display this again" and clicking "OK" were clicked before (locating the frame will timeout because it not be visible)
    WebElement checkbox = wait.until(ExpectedConditions.elementToBeClickable(checkboxLocator));
    WebElement okBtn = wait.until(ExpectedConditions.elementToBeClickable(checkboxLocator));
    checkbox.click();
    okBtn.click();
    driver.switchTo().defaultContent(); // Switch back to default window
} catch (TimeoutException exc) {
    // Handle exception (i.e. log a warning) - This should be thrown as long as the modal dialog doesn't become visible
    // If modal dialog ever becomes visible again, clicking on the checkbox and OK button will be executed again.
}

Something like this should work. Of course, this make some assumptions that might not be true for your case. However, if you use the right locating technique for your modal dialog, you should be able to:

1. Locate the modal window (use By class to locate it)
2. Use WebDriverWait to setup your timeout conditions
3. Tell the driver to switch to it (if this times out, skip steps 3, 4, and 5)
4. Locate the checkbox and OK buttons
5. Click the checkbox and the OK button in that order
6. Tell the driver to switch back to the main window
7. Continue with your test

The problem seems to be when running in a headless environment. If you don't have a window for it to render your browser in, it will hang. You can test this by pasting the same command when you ssh into your machine, but instead do ssh -X me@server.com

I found this documentation on what you can do to fix this: http://www.alittlemadness.com/2008/03/05/running-selenium-headless/

Webdriver utilizes a browser's native support for mapping the DOM element to WebElement object using id/xpath etc.

The JavascriptExecutor.executeScript executes an external script in the context of the currently selected browser window. (similar to an augmented browsing tool like grease monkey, if you ever used), and in case the script returns any DOM element its converted into WebElement object.

One can also say, the click simulated by WebDriver on a browser is similar to what actual user do as compared to one invoked using javascript.

In reality, with WebDriver not all the events can be automated flawlessly with all the web browsers, in fact with different versions of the same Web browser also. (i.e. different version of IE, FF etc behave differently). Still WebDriver is the near best tool available for this.

Once (~4 years back) on a certain version of IE we observed that we can't send right click or may be hover mouse on generated menu links, so we used js to simulate that, which performed very much browser independent way. so you can now conclude what executing external javascript can be good for.

Also, there are automated web testing frameworks which use javascript for everything instead of browser's native support. e.g. :http://en.wikipedia.org/wiki/Sahi_%28software%29

Ref:

• #executeScript%28java.lang.String,%20java.lang.Object...%29
• #findElement%28org.openqa.selenium.By%29

On Linux, you can start up a vncserver on a different display (say, :8 or something) and then have Selenium and your Firefox instances use that display. Works well for us where I work.

  <input attr1='a' attr2='b' attr3='c'>foo</input>

getAttribute(attr1) you get 'a'

getAttribute(attr2) you get 'b'

getAttribute(attr3) you get 'c'

getText() with no parameter you can only get 'foo'