How to use getQueueSize method of org.openqa.selenium.grid.sessionqueue.local.LocalNewSessionQueue class

Selenium supports org.openqa.selenium.JavascriptExecutor. We can get the value of window.performance.memory.usedJSHeapSize at any stage during testing. Below is the code.

  public static void reportMemoryUsage(WebDriver webDriver, String message) {
    ((JavascriptExecutor) webDriver).executeScript("window.gc()");
    try {
        TimeUnit.SECONDS.sleep(2);
    } catch (InterruptedException e) {
        LOGGER.error(e.getLocalizedMessage());
    }
    Double usedJSHeapSize = (Double) ((JavascriptExecutor) webDriver)
            .executeScript("return window.performance.memory.usedJSHeapSize/1024/1024");
    LOGGER.info("Memory Usage at " + message + " - " + usedJSHeapSize + " MB ");
 }

Call this method from your test suite, one at beginning of the test and one at the end. Difference between two usedJSHeapSize values will give the memory leak.

I am forcing garbage collection before taking usedJSHeapSize, to make sure the there is no garbage information collected. To enable gc function on window, you will have to set the -js-flags=--expose-gc option.

ChromeOptions options = new ChromeOptions();
options.addArguments("-js-flags=--expose-gc");
WebDriver webDriver = new ChromeDriver(options);

Yes, that's the default behavior of TestNG and I had introduced it through that pull request to fix the bug https://github.com/cbeust/testng/issues/2022

To set the JVM arguments in intelliJ, choose Run > Edit Configurations, and add this JVM argument in the VM options section after -ea (which would be there by default.

For more information on editing configurations, please refer to the official documentation here

Added screenshot for easy to find in Intellij

Argument value

-ea -Dtestng.dtd.http=true

If the above does not work do at template level, this will fix it, which is

Run--> Edit configuration --> template --> testng

Recently Selenium has launched Selenium 3 and if you are trying to use Firefox latest version then you have to use GeckoDriver:

System.setProperty("webdriver.gecko.driver","G:\\Selenium\\Firefox driver\\geckodriver.exe");
WebDriver driver = new FirefoxDriver();

You can check full documentation from here

In a word, no. It's not possible using the Selenium WebDriver API. This has been discussed ad nauseam in the issue tracker for the project, and the feature will not be added to the API.

I found a google groups discussion on the topic. These links look like promising alternative to Browsermob:

• A Selenium CaptureNetworkTraffic Example in Java
• HOWTO: Collect WebDriver HTTP Request and Response Headers
• Automating the Capture of Web Timings with Selenium 2

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.

Probably all that you need is change the code to :

WebElement element = elements.get(0).findElement(By.xpath(".//x")); //this would search any **x** as a sub-child of your list's elements

The error is because you have a period (.) in the class name, .config-category. The class name does not contain a period in the HTML. I think you are confusing this with CSS selectors where you preface the class name with a period.

You can write a single locator to find all the LIs that you are looking for using CSS selectors. You are looking for DIVs that contain the class name config-category which you can represent as div.config-category. Next you want descendants of that DIV that are LIs. Descendants are represented with a space and then you add li like, div.config-category li. The code below should work.

public void configButtonCount()
{
    List<WebElement> buttons = driver.findElements(By.cssSelector("div.config-category li"));
    System.out.println("List size is: " + buttons.size());
}

CSS selectors are extremely powerful locators and are widely supported and have very good performance, especially vs. XPath locators. I would suggest that you take some time to read up on them and learn the basics. You will find them extremely useful. Here are just a couple resources to get you started:

W3C CSS selectors reference

CSS selectors tips & tricks

The reason for this problem is guava library.

This problem got solved by adding the guava library in maven pom.xml

    <dependency>
        <groupId>com.google.guava</groupId>
        <artifactId>guava</artifactId>
        <version>31.0.1-jre</version>
    </dependency>

One of my friend was also facing this issue and adding this library took care of it as that method ImmutableMap comes from guava

Pasting the error message as well so people will land here as many will have same problem

java.lang.NoSuchMethodError: com.google.common.collect.ImmutableMap.of(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Lcom/google/common/collect/ImmutableMap;

at org.openqa.selenium.chrome.AddHasCasting.getAdditionalCommands(AddHasCasting.java:38)
at org.openqa.selenium.chrome.ChromeDriver$ChromeDriverCommandExecutor.getExtraCommands(ChromeDriver.java:123)