3

After implementing filepicker.io, some of our Selenium regression tests have started failing. The failures (intermittent, but more often than not in some circumstances) are that clicks are ignored on WebElements found via XPath queries. e.g.

driver.findElement(By.xpath("//a[text()='Demo data']")).click();

Adding a Sleep(2000) between findElement() and click() generally resolves the problem. (I say generally because Sleep(1000) was mostly enough, until it wasn't, so I made it Sleep(2000)...)

Checking element.isDisplayed() has not helped. The problem disappears if we stop including the filepicker.io JavaScript file.

Is it something to do with filepicker.io introducing an IFRAME? We have also noticed that JQuery's document.ready() seems to be now invoked twice.

Oliver Bock
  • 4,829
  • 5
  • 38
  • 62

2 Answers2

0

As usual with this kind of problems, you are trying to find an element that is not yet available on the page due to AJAX request still downloading/processing it. You need to wait for the element to appear on the page.

There are three ways to do this:

  1. Using sleep(). This is the discouraged way. You should not use hardcoded sleeps, because you'll either wait too long (making the tests unnecessarily slow) or too short (failing the test).
  2. Use Implicit wait. That will always wait for an element if it's not found.

    driver.manage().timeouts().implicitlyWait(5, TimeUnit.SECONDS);
    
  3. Use explicit wait. That enables you to wait explicitly for one element to (dis)appear / become available / whatever.

    WebDriverWait wait = new WebDriverWait(driver, 10);
    WebElement element = wait.until(ExpectedConditions.elementToBeClickable(By.linkText("Demo data")));
    
Petr Janeček
  • 37,768
  • 12
  • 121
  • 145
  • I don't think that's it. findElement() is returning the element without throwing an exception (hence it is in the DOM), and click() does not throw an exception (hence it is visible). It is not an input element so I understand that enabled is not relevant. – Oliver Bock Jun 12 '13 at 00:26
  • @OliverBock Ohh. I must have misread the question, my bad, I'm sorry. There have been bugs with Firefox and iframes - sometimes it clicks at wrong coordinates. Try with a different browser, try to detect where (whether) it actually clicks. Try `executeScript("arguments[0].click()", theElementToClick);` as a workaround. – Petr Janeček Jun 12 '13 at 00:49
0

We now run this code first after opening any page that includes filepicker.js:

while (FindElementsMaybeNone(By.cssSelector("#filepicker_comm_iframe")).size() == 0)
    Sleep(50);
while (driver.switchTo().frame("filepicker_comm_iframe") == null)
    Sleep(50);
driver.switchTo().defaultContent();

We guess that filepicker's dynamic IFRAME insertion is discombobulating Firefox or Selenium. I'm not marking this as the answer because I don't really know why it works.

Oliver Bock
  • 4,829
  • 5
  • 38
  • 62