How to use titleIs method of org.openqa.selenium.support.ui.ExpectedConditions class

The problem

The problem you are probably facing is that the method returns the right (and valid!) element, but when you're trying to access it a second later, it is stale and throws.

This usually arises when:

1. You click something that loads a new page asynchronously or at least changes it.
2. You immediatelly (before the page load could finish) search for an element ... and you find it!
3. The page finally unloads and the new one loads up.
4. You try to access your previously found element, but now it's stale, even though the new page contains it, too.

The solutions

There are four ways to solve it I know about:

1. Use proper waits

   Use proper waits after every anticipated page-load when facing asynchronous pages. Insert an explicit wait after the initial click and wait for the new page / new content to load. Only after that you can try to search for the element you want. This should be the first thing you'll do. It will increase the robustness of your tests greatly.

2. The way you did it

   I have been using a variant of your method for two years now (together with the technique above in solution 1) and it absolutely works most of the time and fails only on strange WebDriver bugs. Try to access the found element right after it is found (before returning from the method) via a .isDisplayed() method or something. If it throws, you already know how to search again. If it passes, you have one more (false) assurance.

3. Use a WebElement that re-finds itself when stale

   Write a WebElement decorator that remembers how it was found and re-find it when it's accessed and throws. This obviously forces you to use custom findElement() methods that would return instances of your decorator (or, better yet, a decorated WebDriver that would return your instances from usual findElement() and findElemens() methods). Do it like this:

   public class NeverStaleWebElement implements WebElement {
       private WebElement element;
       private final WebDriver driver;
       private final By foundBy;
   
       public NeverStaleWebElement(WebElement element, WebDriver driver, By foundBy) {
           this.element = element;
           this.driver = driver;
           this.foundBy = foundBy;
       }
   
       @Override
       public void click() {
           try {
               element.click();
           } catch (StaleElementReferenceException e) {
               // log exception
   
               // assumes implicit wait, use custom findElement() methods for custom behaviour
               element = driver.findElement(foundBy);
   
               // recursion, consider a conditioned loop instead
               click();
           }
       }
   
       // ... similar for other methods, too
   
   }
   

   Note that while I think that the foundBy info should be accessible from the generic WebElements to make this easier, Selenium developers consider it a mistake to try something like this and have chosen not to make this information public. It's arguably a bad practice to re-find on stale elements, because you're re-finding elements implicitly without any mechanism for checking whether it's justified. The re-finding mechanism could potentially find a completely different element and not the same one again. Also, it fails horribly with findElements() when there are many found elements (you either need to disallow re-finding on elements found by findElements(), or remember the how-manyeth your element was from the returned List).

   I think it would be useful sometimes, but it's true that nobody would ever use options 1 and 2 which are obviously much better solutions for the robustness of your tests. Use them and only after you're sure you need this, go for it.

4. Use a task queue (that can rerun past tasks)

   Implement your whole workflow in a new way!

   • Make a central queue of jobs to run. Make this queue remember past jobs.
   • Implement every needed task ("find an element and click it", "find an element and send keys to it" etc.) via the Command pattern way. When called, add the task to the central queue which will then (either synchronously or asynchronously, doesn't matter) run it.
   • Annotate every task with @LoadsNewPage, @Reversible etc. as needed.
   • Most of your tasks will handle their exceptions by themselves, they should be stand-alone.
   • When the queue would encounter a stale element exception, it would take the last task from the task history and re-run it to try again.

   This would obviously take a lot of effort and if not thought through very well, could backfire soon. I used a (lot more complex and powerful) variant of this for resuming failed tests after I manually fixed the page they were on. Under some conditions (for example, on a StaleElementException), a fail would not end the test right away, but would wait (before finally time-outing after 15 seconds), popping up an informative window and giving the user an option to manually refresh the page / click the right button / fix the form / whatever. It would then re-run the failed task or even give a possibility to go some steps back in history (e.g. to the last @LoadsNewPage job).

Final nitpicks

All that said, your original solution could use some polishing. You could combine the two methods into one, more general (or at least make them delegate to this one to reduce code repetition):

WebElement getStaleElem(By by, WebDriver driver) {
    try {
        return driver.findElement(by);
    } catch (StaleElementReferenceException e) {
        System.out.println("Attempting to recover from StaleElementReferenceException ...");
        return getStaleElem(by, driver);
    } catch (NoSuchElementException ele) {
        System.out.println("Attempting to recover from NoSuchElementException ...");
        return getStaleElem(by, driver);
    }
}

With Java 7, even a single multicatch block would be sufficient:

WebElement getStaleElem(By by, WebDriver driver) {
    try {
        return driver.findElement(by);
    } catch (StaleElementReferenceException | NoSuchElementException e) {
        System.out.println("Attempting to recover from " + e.getClass().getSimpleName() + "...");
        return getStaleElem(by, driver);
    }
}

This way, you can greatly reduce the amount of code you need to maintain.

Yes, all correct.

Here's a screenshot of where to find font-size through Firebug.

Since the ids are supposed to be unique (at least for this page), you don't need findElements to find a list of elements with id by-id and loop through, instead, you use findElement to get the element directly.

try{
        WebElement byId = driver.findElement(By.id("by-id"));

        System.out.println(byId.getTagName());

        System.out.println("get the text for web element with id='by-id' ");
        System.out.println("------------------------------------------------------------");
        System.out.println(byId.getText());
        System.out.println("------------------------------------------------------------");
        System.out.println(byId.getAttribute("id"));
        System.out.println(byId.getCssValue("font-size"));
    }
}

If you want to scroll on the firefox window using selenium webdriver, one of the way is to use javaScript in the java code, The javeScript code to scroll down is as follows:

WebDriver driver = new FirefoxDriver();
JavascriptExecutor js = (JavascriptExecutor)driver;
js.executeScript("window.scrollTo(0,Math.max(document.documentElement.scrollHeight," + "document.body.scrollHeight,document.documentElement.clientHeight));");

Here is how I am sending character by character using Selenium Webdriver (in Java). This way in the back-end, I verify at each letter press if the character exists in the input. Normal element.sendKeys() is not working well for me 2 out of 5 times - the last letter is missing, I guess something is buggy with Selenium Webdriver, I don't know. Try the code below, it works 100% of the time for me.

public void TypeInField(String xpath, String value){
    String val = value; 
    WebElement element = driver.findElement(By.xpath(xpath));
    element.clear();

    for (int i = 0; i < val.length(); i++){
        char c = val.charAt(i);
        String s = new StringBuilder().append(c).toString();
        element.sendKeys(s);
    }       
}

As you see, I get the value needed to be typed and in the for loop, I take each character, convert it to string and send it to textbox. Also, I have a search for xpath, you can change that to id, or classname, or whatever you want.

This error message...

org.openqa.selenium.SessionNotCreatedException: session not created exception from tab crashed (Session info: chrome=65.0.3325.181) (Driver info: chromedriver=2.37.544315 (730aa6a5fdba159ac9f4c1e8cbc59bf1b5ce12b7),platform=Windows NT 6.1.7601 SP1 x86_64) (WARNING: The server did not provide any stacktrace information) Command duration or timeout: 2.50 seconds Build info: version: '3.11.0', revision: 'e59cfb3', time: '2018-03-11T20:26:55.152Z' System info: host: 'USNBDFV9K12', ip: '10.23.4.80', os.name: 'Windows 7', os.arch: 'amd64', os.version: '6.1', java.version: '1.8.0_131' Driver info: driver.version: ChromeDriver

The error stack trace clearly shows your ChromeDriver binary details are not getting detected back as in :

Driver info: driver.version: ChromeDriver

Though your chromedriver=2.37.544315 and Chrome: 65.0.3325.181 are compatible your main issue is java.version: '1.8.0_131' which is ancient.

Solution

• Upgrade JDK to recent levels JDK 8u162
• Clean your Project Workspace through your IDE and Rebuild your project with required dependencies only.
• Use CCleaner tool to wipe off all the OS chores before and after the execution of your test Suite.
• If your base Web Client version is too old, then uninstall it through Revo Uninstaller and install a recent GA and released version of Web Client.
• Take a system Reboot.
• Execute your @Test.

from tab crashed

from tab crashed was WIP(Work In Progress) with the Chromium Team for quite some time now which relates to Linux attempting to always use /dev/shm for non-executable memory. Here are the references :

• Linux: Chrome/Chromium SIGBUS/Aw, Snap! on small /dev/shm
• Chrome crashes/fails to load when /dev/shm is too small, and location can't be overridden
• As per Comment61#Issue 736452 the fix seems to be have landed with Chrome v65.0.3299.6

Hence you may need to bump up to Chrome v65.0.3299.6 or later.

No, it makes no difference.

String strVariable = "String"
sendKeys(strVariable).perform();

And...

sendKeys("String").perform();

... are identical in Selenium.

The reason is nothing to do with Selenium but the way Java works. It's a bit complicated to explain, but in Java variables in methods are passed by value, not by reference. So, in the first version, the value of the variable (i.e. the string) is passed into the method, not the variable reference itself. Which means, as far as the sendKeys() method is concerned, the first and second versions are identical.

It is also important to point out that Strings in Java are immutable, so neither the sendKeys method nor anything outside of the method could change the value of the String itself.

Unfortunately Selenium WebDriver 2.53.0 is not compatible with Firefox 47.0. The WebDriver component which handles Firefox browsers (FirefoxDriver) will be discontinued. As of version 3.0, Selenium WebDriver will need the geckodriver binary to manage Firefox browsers. More info here and here.

Therefore, in order to use Firefox 47.0 as browser with Selenium WebDriver 2.53.0, you need to download the Firefox driver (which is a binary file called geckodriver as of version 0.8.0, and formerly wires) and export its absolute path to the variable webdriver.gecko.driver as a system property in your Java code:

System.setProperty("webdriver.gecko.driver", "/path/to/geckodriver");

Luckily, the library WebDriverManager can do this work for you, i.e. download the proper Marionette binary for your machine (Linux, Mac, or Windows) and export the value of the proper system property. To use this library, you need to include this dependency into your project:

<dependency>
    <groupId>io.github.bonigarcia</groupId>
    <artifactId>webdrivermanager</artifactId>
    <version>5.1.0</version>
</dependency>

... and then execute this line in your program before using WebDriver:

WebDriverManager.firefoxdriver().setup();

A complete running example of a JUnit 4 test case using WebDriver could be as follows:

public class FirefoxTest {

    protected WebDriver driver;

    @BeforeClass
    public static void setupClass() {
        WebDriverManager.firefoxdriver().setup();
    }

    @Before
    public void setupTest() {
        driver = new FirefoxDriver();
    }

    @After
    public void teardown() {
        if (driver != null) {
            driver.quit();
        }
    }

    @Test
    public void test() {
        // Your test code here
    }
}

Take into account that Marionette will be the only option for future (for WebDriver 3+ and Firefox 48+), but currently (version 0.9.0 at writing time) is not very stable. Take a look to the Marionette roadmap for further details.

UPDATE

Selenium WebDriver 2.53.1 has been released on 30th June 2016. FirefoxDriver is working again with Firefox 47.0.1 as browser.

Many GWT elements comes with ensureDebugId (method on UIObject) to allow you to explicitly set Ids to elements for testing and debugging purpose. You also need to inherit the module

 <inherits name="com.google.gwt.user.Debug"/> 

to make it work. The advantage of this is, you can remove the trace from the production deployment by removing the inherited module in during prod mode compile. Hence there wont be code changes to remove unnecessary Ids.

Try to wait until element that gets click disappeared:

new WebDriverWait(driver, 10).until(ExpectedConditions.invisibilityOfElementLocated(By.xpath('//div[@style="position: absolute; left: 0px; top: 0px; width: 100%; height: 100%; z-index: 30; background-color: rgb(221, 221, 221); opacity: 0.4;"]')));

As this answer was downvoted, I add some more details to explain why it could be acceptable solution.

It's a known issue (I personally have faced it few times) of chromedriver: chromedriver sometimes ignores modal windows such as "Page loading in progress"

and "thinks" that target element (that is covered by modal window) actually visible and clickable and tries to make click which is received by modal window.

So it makes sense to wait until modal window disappeared.