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

this below code works for me in Selenium 3 and chrome version 58.

    WebDriver driver = new ChromeDriver();
    driver.get("http://yahoo.com");  
    ((JavascriptExecutor)driver).executeScript("window.open()");
    ArrayList<String> tabs = new ArrayList<String>(driver.getWindowHandles());
    driver.switchTo().window(tabs.get(1));
    driver.get("http://google.com");

According to this: http://docs.seleniumhq.org/docs/appendix_migrating_from_rc_to_webdriver.jsp

You might be using the browserbot to obtain a handle to the current window or document of the test. Fortunately, WebDriver always evaluates JS in the context of the current window, so you can use “window” or “document” directly.

Alternatively, you might be using the browserbot to locate elements. In WebDriver, the idiom for doing this is to first locate the element, and then pass that as an argument to the Javascript. Thus:

So does the following work in webdriver?

WebDriver driver = new FirefoxDriver();
((JavascriptExecutor) driver)
  .executeScript("var s=window.document.createElement('script');\
  s.src='somescript.js';\
  window.document.head.appendChild(s);");

You can control how the Firefox driver chooses the profile. Set the webdriver.firefox.profile property to the name of the profile you want to use. Most folks think this is a bad idea, because you'll inherit all the cookies, cache contents, etc. of the previous uses of the profile, but it's allowed if you really want to do it.

For example:

System.setProperty("webdriver.firefox.profile", "MySeleniumProfile");
WebDriver driver = new FirefoxDriver(...);

UPDATE - From Ranhiru

How I handled it for Java

FirefoxProfile profile = new FirefoxProfile(new File("D:\\Selenium Profile"));                  
WebDriver driver = new FirefoxDriver(profile);

Then I changed settings in Firefox to clear all cookies and cache when exiting. Look here on how to do it.

The element is blinking because of a feature of the IE driver called "persistent hovers." This feature is of dubious value, but is required because of the brain-dead way IE (the browser, not the driver) responds to WM_MOUSEMOVE messages when using the SendMessage API.

You have a few options. You can turn persistent hovers off by using code like the following:

InternetExplorerOptions options = new InternetExplorerOptions();
options.EnablePersistentHover = false;
IWebDriver driver = new InternetExplorerDriver(options);

Be aware, though that this will subject you to the whims of where the physical mouse cursor is on the screen when you attempt to hover. If that's not acceptable, you have a couple of other approaches you could take. First, you could turn off so-called "native events," which would cause the driver to rely solely on synthesized JavaScript events. This approach has its own pitfalls, due to relying only on JavaScript to synthesize the mouse events.

InternetExplorerOptions options = new InternetExplorerOptions();
options.EnableNativeEvents = false;
IWebDriver driver = new InternetExplorerDriver(options);

Finally, you could migrate from using the default SendMessage Windows API to code that uses the more correct SendInput API. This is done with the RequireWindowFocus property. Its drawback is that the mouse input is injected at a very low level in the system, which requires the IE window to be the foreground window on the system.

InternetExplorerOptions options = new InternetExplorerOptions();
options.RequireWindowFocus = true;
IWebDriver driver = new InternetExplorerDriver(options);

As a final note, do not attempt to set all of these properties at once; pick an approach and stick with it. Several of them are mutually exclusive, and the interaction between them is undefined.

File pathToBinary = new File("C:\\user\\Programme\\FirefoxPortable\\App\\Firefox\\firefox.exe");
FirefoxBinary ffBinary = new FirefoxBinary(pathToBinary);
FirefoxProfile firefoxProfile = new FirefoxProfile();       
WebDriver driver = new FirefoxDriver(ffBinary,firefoxProfile);

Element.scrollIntoView()

Element.scrollIntoView() method scrolls the element on which it's called into the Viewport of the browser window.

Syntax

• element.scrollIntoView()
• element.scrollIntoView(alignToTop) // Boolean parameter
• element.scrollIntoView(scrollIntoViewOptions) // Object parameter

Parameters

The parameters for this method are:

• alignToTop (Optional): Is a Boolean value, if true, the top of the element will be aligned to the top of the visible area of the scrollable ancestor. This is the default value. If false, the bottom of the element will be aligned to the bottom of the visible area of the scrollable ancestor. Corresponds to scrollIntoViewOptions: {block: "end", inline: "nearest"}.
• scrollIntoViewOptions (Optional): Is an Object with the following properties:
• behavior (Optional): Defines the transition animation. One of "auto" or "smooth". Defaults to "auto".
• block (Optional): Defines vertical alignment. One of "start", "center", "end", or "nearest". Defaults to "start".
• inline (Optional): Defines horizontal alignment. One of "start", "center", "end", or "nearest". Defaults to "nearest".

This usecase

As per your line of code:

((JavascriptExecutor) driver).executeScript("arguments[0].scrollIntoView(true);", element);

the argument true refers to boolean value for alignToTop. Hence the issue.

Solution

To automate horizontal scrolling you need to pass the argument for the inline parameter either among the following:

• start
• center
• end
• nearest

Alternative

As an alternative you can use either of the following options

• scrollLeft(): Element.scrollLeft() property gets or sets the number of pixels that an element's content is scrolled from its left edge. If the element's direction is rtl (right-to-left), then scrollLeft is 0 when the scrollbar is at its rightmost position (at the start of the scrolled content), and then increasingly negative as you scroll towards the end of the content.
• scrollWidth(): Element.scrollWidth() read-only property is a measurement of the width of an element's content, including content not visible on the screen due to overflow.

Outro

You can find a couple of relevant detailed discussion in:

• What is the difference between the different scroll options?
• Selenium python Error: element could not be scrolled into view

The server:

import org.openqa.selenium.server.SeleniumServer;
public class SeleniumServerControl {
  private static final SeleniumServerControl instance = new SeleniumServerControl();
  public static SeleniumServerControl getInstance() {
    return instance;
  }
  private SeleniumServer server = null;
  protected SeleniumServerControl() {
  }
  public void startSeleniumServer() {
    if (server == null) {
      try {
        server = new SeleniumServer(SeleniumServer.DEFAULT_PORT);
        System.out.println(" selenium server " + server.toString());
      } catch (Exception e) {
        System.err.println("Could not create Selenium Server because of: "
            + e.getMessage());
        e.printStackTrace();
      }
    }
    try {
      server.start();
    } catch (Exception e) {
      System.err.println("Could not start Selenium Server because of: "
          + e.getMessage());
      e.printStackTrace();
    }
  }
  public void stopSeleniumServer() {
    if (server != null) {
      try {
        server.stop();
        server = null;
      } catch (Exception e) {
        System.err.println("Could not stop Selenium Server because of: "
            + e.getMessage());
        e.printStackTrace();
      }
    }
  }
}

The client:

browser = new DefaultSelenium("localhost", 4444, "*firefox", "http://www.google.com");
browser.start();

Well, there are two types of wait: explicit and implicit wait. The idea of explicit wait is

WebDriverWait.until(condition-that-finds-the-element);

The concept of implicit wait is

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

You can get difference in details here.

In such situations I'd prefer using explicit wait (fluentWait in particular):

public WebElement fluentWait(final By locator) {
    Wait<WebDriver> wait = new FluentWait<WebDriver>(driver)
            .withTimeout(30, TimeUnit.SECONDS)
            .pollingEvery(5, TimeUnit.SECONDS)
            .ignoring(NoSuchElementException.class);

    WebElement foo = wait.until(new Function<WebDriver, WebElement>() {
        public WebElement apply(WebDriver driver) {
            return driver.findElement(locator);
        }
    });

    return  foo;
};

fluentWait function returns your found web element. From the documentation on fluentWait: An implementation of the Wait interface that may have its timeout and polling interval configured on the fly. Each FluentWait instance defines the maximum amount of time to wait for a condition, as well as the frequency with which to check the condition. Furthermore, the user may configure the wait to ignore specific types of exceptions whilst waiting, such as NoSuchElementExceptions when searching for an element on the page. Details you can get here

Usage of fluentWait in your case be the following:

WebElement textbox = fluentWait(By.id("textbox"));

This approach IMHO better as you do not know exactly how much time to wait and in polling interval you can set arbitrary timevalue which element presence will be verified through . Regards.

If you are able to set a fixed number of calls to expect, it can be done with an ArgumentCaptor:

import static org.hamcrest.CoreMatchers.hasItem;

@Captor ArgumentCaptor<String> arg;

@Before
public void setUp() throws Exception {
    // init the @Captor
    initMocks(this);
}

@Test
public void testWithTimeoutCallOrderDoesntMatter() throws Exception {
    // there must be exactly 99 calls
    verify(myMock, timeout(5000).times(99)).myMethod(arg.capture());
    assertThat(arg.getAllValues(), hasItem("expectedArg"));
}

Another way is to specify all the expected values to verify, but those need to be provided in the exact order that they are invoked. The difference to the above solution is that this doesn't fail even if the mock is additionally called with some non-verified arguments. In other words, no need to know the number of total invocations. Code example:

@Test
public void testWithTimeoutFollowingCallsDoNotMatter() throws Exception {
    // the order until expected arg is specific
    verify(callback, timeout(5000)).call("firstExpectedArg");
    verify(callback, timeout(5000)).call("expectedArg");
    // no need to tell more, if additional calls come after the expected arg
    // verify(callback, timeout(5000)).call("randomArg");
}