How to use isResidentCredential method of org.openqa.selenium.virtualauthenticator.Credential class

The general principle is to check the value of window.pageYOffset in the browser. If your button scrolls completely back to the top then window.pageYOffset should have a value of 0. Assuming the driver variable holds your WebDriver instance:

JavascriptExecutor executor = (JavascriptExecutor) driver;
Long value = (Long) executor.executeScript("return window.pageYOffset;");

You can then check that value is 0. executeScript is used to run JavaScript code in the browser.

This answer initially mentioned scrollY but there's no support for it on IE. The MDN page on it, says:

For cross-browser compatibility, use window.pageYOffset instead of window.scrollY. Additionally, older versions of Internet Explorer (< 9) do not support either property and must be worked around by checking other non-standard properties. A fully compatible example:

var supportPageOffset = window.pageXOffset !== undefined;
var isCSS1Compat = ((document.compatMode || "") === "CSS1Compat");

var x = supportPageOffset ? window.pageXOffset : isCSS1Compat ? document.documentElement.scrollLeft : document.body.scrollLeft;
var y = supportPageOffset ? window.pageYOffset : isCSS1Compat ? document.documentElement.scrollTop : document.body.scrollTop;

Thanks to R. Oosterholt for the "heads up".

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)

Currently, there is no way to clear the cache through the web driver API. However, if you can start a new instance of the browser each time, the cache should be cleared in FF and Chrome because a new profile is created on each launch.

The comments for issue #40 (Clear cache) in the Selenium issue tracker list two potential solutions to your problem if creating a new browser instance isn't possible:

1. Clear the IE cache from the command line
2. Disable the FF cache using a custom profile

HTH

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()

Using an explicit wait worked for me (tried both chrome and firefox):

WebDriverWait wait = new WebDriverWait(driver, 10);
WebElement element = wait.until(
    ExpectedConditions.visibilityOfElementLocated(By.id("ctl62_txtSearchLastName"))
);

element.sendKeys("test");

Resulted into:

What is happening here is the creation of an anonymous class that inherits from ExpectedCondition. In the body of this class he is then overriding the method apply(...).

This can actually be easily done.

The idea is to get access to the WebDriver instance and run the JavaScript on it (if it supports it). Then there's a lot of validating, because we need to make sure we only return what we promised.

The ByJavaScript class itself will look like this:

public class ByJavaScript extends By implements Serializable {
    private final String script;

    public ByJavaScript(String script) {
        checkNotNull(script, "Cannot find elements with a null JavaScript expression.");
        this.script = script;
    }

    @Override
    public List<WebElement> findElements(SearchContext context) {
        JavascriptExecutor js = getJavascriptExecutorFromSearchContext(context);

        // call the JS, inspect and validate response
        Object response = js.executeScript(script);
        List<WebElement> elements = getElementListFromJsResponse(response);

        // filter out the elements that aren't descendants of the context node
        if (context instanceof WebElement) {
            filterOutElementsWithoutCommonAncestor(elements, (WebElement)context);
        }

        return elements;
    }

    private static JavascriptExecutor getJavascriptExecutorFromSearchContext(SearchContext context) {
        if (context instanceof JavascriptExecutor) {
            // context is most likely the whole WebDriver
            return (JavascriptExecutor)context;
        }
        if (context instanceof WrapsDriver) {
            // context is most likely some WebElement
            WebDriver driver = ((WrapsDriver)context).getWrappedDriver();
            checkState(driver instanceof JavascriptExecutor, "This WebDriver doesn't support JavaScript.");
            return (JavascriptExecutor)driver;
        }
        throw new IllegalStateException("We can't invoke JavaScript from this context.");
    }

    @SuppressWarnings("unchecked")  // cast thoroughly checked
    private static List<WebElement> getElementListFromJsResponse(Object response) {
        if (response == null) {
            // no element found
            return Lists.newArrayList();
        }
        if (response instanceof WebElement) {
            // a single element found
            return Lists.newArrayList((WebElement)response);
        }
        if (response instanceof List) {
            // found multiple things, check whether every one of them is a WebElement
            checkArgument(
                    Iterables.all((List<?>)response, Predicates.instanceOf(WebElement.class)),
                    "The JavaScript query returned something that isn't a WebElement.");
            return (List<WebElement>)response;  // cast is checked as far as we can tell
        }
        throw new IllegalArgumentException("The JavaScript query returned something that isn't a WebElement.");
    }

    private static void filterOutElementsWithoutCommonAncestor(List<WebElement> elements, WebElement ancestor) {
        for (Iterator<WebElement> iter = elements.iterator(); iter.hasNext(); ) {
            WebElement elem = iter.next();

            // iterate over ancestors
            while (!elem.equals(ancestor) && !elem.getTagName().equals("html")) {
                elem = elem.findElement(By.xpath("./.."));
            }

            if (!elem.equals(ancestor)) {
                iter.remove();
            }
        }
    }

    @Override
    public String toString() {
          return "By.javaScript: \"" + script + "\"";
    }

}

^{This code uses the Google Guava library. It is a dependency of Selenium, so you should have it on your classpath. But if there's something you don't understand, look into Guava.}

Things to consider:

1. Document the whole thing.
2. Use better and more helpful exceptions. Consider some custom subclasses of WebDriverException. Also add more helpful messages and info.
3. Restrict the class' visibility to package. Or embed it into a static factory (as seen in the original By class) so that it won't be accessible directly etc.
4. Write tests. I have tried the most obvious usages (element can't be found, search from driver, search from some context) and everything seems to be ok, but I didn't test it extensively.

Usage:

WebElement elem = driver.findElement(new ByJavaScript("return document.querySelector('.haha');"));

Now, the original By class is a static factory that gives out various implementations of itself. Unfortunately, we can't add a new static method to it (without changing its source), so we won't be able to type By.javascript("return something;"). We have to create our own static factory to get something similar:

public class MyBy {
    /**
     * Returns a {@code By} which locates elements by the JavaScript expression passed to it.
     * 
     * @param script The JavaScript expression to run and whose result to return
     */
    public static By javascript(String script) {
        return new ByJavaScript(script);
    }
}

Usage:

WebElement elem = driver.findElement(MyBy.javascript("return document.querySelector('.haha');"));

The difference of findElement between WebElement and WebDriver is the context.

Whereas the context of WebDriveris the current page, the context of WebElement is that element. WebDriver will search across the whole document, while WebElement will try to find the first child element from that node.

Note that when searching with WebElement via XPath, starting with // will still search across the entire document, not just the children of the current node. You can use .// to limit the search results to the children of that WebElement.

First off, there are no "best practices," just ones that work well in your particular context. Sorry, that's an old gripe of mine...

I wouldn't spend the effort for custom attributes unless you can't work with an existing approach. I prefer using existing locators (find logic) where possible.

Whenever possible, use ID attributes. If the page is valid HTML, then IDs are unique on the page. They're extraordinarily fast for resolution in every browser, and the UI can change dramatically but your script will still locate the element.

Sometimes IDs aren't the right choice. Dynamically generated IDs are almost always the wrong choice when you're working with something like a grid control. You rely on an id that is likely tied to the specific row position and then you're screwed if your row changes.

In some of these cases your devs can help you out by appending or prepending constant values to a dynamically generated ID value. ASP.NET Webforms does crazy stuff with dynamically generated values, so I've used a suffix to my advantage several times.

Link text, name attribute values, and CSS selectors (JQuery style) are great second choices when you can't get a stable, reliable ID, or one's just not available.

XPath is my last choice in nearly all situations. It's slow, can be extremely brittle, and is hard to deal with when it's a complex XPath. That said, if you need to move up and down the page DOM for your locators, then it's the only choice.

Using one of the existing FindBy methods means you'll be using a well-understood, well-supported locator strategy. That's a big bonus when you're trying to figure out an old test, or when onboarding someone new to your team.

That's my $0.02.