Is Selenium 2.0 waiting for element / page to load? - selenium

I heard that Selenium 2.0. is waiting for element or page to load by default, so there is no longer need to write specific methods like 'waitForElementToLoad' after calling click method.
Is it true? If yes, why can't I find it anywhere in documentation? I constantly find some posts like this, where it's only mentioned:
Selenium - don't wait until all elements are presented
Please advice where can I find any proof of that, what methods are waiting for element to load, and from which version it is implemented?
I am using Selenium 2.0 with Chrome Driver.
Thank you.

As in docs (http://docs.seleniumhq.org/docs/04_webdriver_advanced.jsp) :
"An implicit wait is to tell WebDriver to poll the DOM for a certain amount of time when trying to find an element or elements if they are not immediately available. The default setting is 0. Once set, the implicit wait is set for the life of the WebDriver object instance."
So, you need to set it manually, ie need to wait elements to load. By default Selenium doesn't wait, as written above.
Also here: https://sqa.stackexchange.com/questions/2606/what-is-seleniums-default-timeout-for-page-loading is mentioned that "The default WebDriver setting for timeouts is never"

Related

Why is there no "scroll down/up" functionality with Selenium Webdriver?

Every implementation of scrolling I have seen requires executing Javascript (scrollTop, scrollTo for example), rather than an available method in Selenium Webdriver to perform this action. Since Webdriver is designed to perform the same interactions in a browser that a user might take, why is this not found anywhere?
I understand that using Webdriver to interact with an element in the DOM saves from having to scroll elements, however some libraries like ReactVirtualized are designed to only render visible rows, making automation that much more difficult.
Are you using Capybara (as your question is tagged) or selenium-webdriver directly?
If using Capybara then you want the scroll_to method - https://www.rubydoc.info/gems/capybara/Capybara/Node/Element#scroll_to-instance_method - which was recently added.
If you're using selenium-webdriver directly, it's because for a long time there was insistence by some of the writers of the WebDriver spec that scrolling wasn't necessary. That insistence changed at the last WebDriver spec meeting but details of how scrolling should work haven't actually been added to the spec yet.

Browser runs faster than webdriver selenium command

I am performing an operation using selenium webdriver to wait for an element until an element is visible. After a few milliseconds, it gets disappeared(Expected).Generally we use explicit wait to synchronize with browser because browser is slower. But in this case, browser is faster and before command waits for the visibility , the element disappears hence failing the operation.
It would be great if anyone can help regarding the issue.
PS I am using jmeter webdriver plugin.
Thanks.
You could handle exception which breaks your validation (ignore NoSuchelementException but fail validation on TimeoutException) or create waiting method which waits for element to appear and after that wait to disappear.

Using implicit wait in selenium

I am a beginner. I understand what waits basically does but I am confused over how different tutorials over the internet place it and explain it. For example, in the below code it is placed before loading the URL. So, is it only to wait for the URL to be loaded or for finding the element or both? Is is true that if I use an implicit wait once in my try block, it will be applicable for every element search I am performing in my code?
from selenium import webdriver
driver = webdriver.Firefox()
driver.implicitly_wait(10) # seconds
driver.get("http://somedomain/url_that_delays_loading")
myDynamicElement = driver.find_element_by_id("myDynamicElement")
ImplicitWait
ImplicitWait as per the Java Docs is to specify the amount of time the WebDriver instance i.e. the driver should wait when searching for an element if it is not immediately present in the HTML DOM in-terms of NANOSECONDS, MICROSECONDS, MILLISECONDS, SECONDS, MINUTES, HOURS or DAYS when trying to find an element or elements if they are not immediately available. The default setting is 0 which means the driver when finds an instruction to find an element or elements, the search starts and results are available on immediate basis.
In this case, after a fresh loading of a Webpage an element or elements may be / may not be found on an immediate search. So your Automation Framework may be facing any of these exceptions:
NoSuchElementException
TimeoutException
ElementNotVisibleException
ElementNotSelectableException
Hence we introduce ImplicitWait. By inducing ImplicitWait the driver will poll the DOM Tree until the element has been found for the configured amount of time looking out for the element or elements before throwing a NoSuchElementException. By that time the element or elements for which you had been looking for may be available in the HTML DOM. As in your code you have already set ImplicitWait to a value of 10 seconds, the driver will poll the HTML DOM for 10 seconds.
Python:
driver.implicitly_wait(10)
Java:
driver.manage().timeouts().implicitlyWait(10, TimeUnit.SECONDS);
DotNet:
driver.Manage().Timeouts().ImplicitWait = TimeSpan.FromSeconds(10);
Finally, once you set the ImplicitWait, the WebDriver instance i.e. the driver is able to carry this configuration till its lifetime. But if you need to change the coarse of time for the WebDriver instance i.e. the driver to wait then you can reconfigure it as follows:
Python:
driver.implicitly_wait(5)
Java:
driver.manage().timeouts().implicitlyWait(5, TimeUnit.SECONDS);
DotNet:
driver.Manage().Timeouts().ImplicitWait = TimeSpan.FromSeconds(5);
If at any point of time you want to nullify the ImplicitWait you can reconfigure it as follows:
Python:
driver.implicitly_wait(0)
Java:
driver.manage().timeouts().implicitlyWait(0, TimeUnit.SECONDS);
DotNet:
driver.Manage().Timeouts().ImplicitWait = TimeSpan.FromSeconds(0);
Answering your questions
...Wait for the URL... : No, ImplicitWait have no effect on page loading.
...For finding the element... : Yes, ImplicitWait will define the coarse of time the WebDriver instance will wait looking out for the element or elements.
...Implicit wait once... : Yes, you need to configure ImplicitWait only once and it is applicable throughout the lifetime of the WebDriver instance.
...Every element search... : Yes, applicable when ever findElement() or findElements() is invoked.
yes, implicit_wait is globally applicable. so once you set it's applied to all the element.
I would not suggest to use implicit_wait unless your application is too slow. You could use explicit wait or any other wait based on your requirement from the following page.
it's a JAVADOC but implementation should be same for python as well.
https://seleniumhq.github.io/selenium/docs/api/java/org/openqa/selenium/WebDriver.Timeouts.html#implicitlyWait-long-java.util.concurrent.TimeUnit-
Implicit wait is applicable for all the web elements where as Explicit wait is applicable only for the element it is specified.
Explicit wait is more intelligent and are really use full in handling Ajax on the other hand implicit wait is generally used to handle application sync issues.

Implicit Wait in selenium waits for the page to get loaded or all the elements to get loaded

Implicit Wait in selenium waits for the page to get loaded or all the elements to get loaded.
suppose there is a web page, where the page is loaded while some of the web elements are still loading. So in this scenario if we use Selenium Implicit wait, it will wait for the page loading or for all the elements to get loaded.
Please help with this confusion.
Actually none of them ;)
You can think that implicit wait is something similar to a "timeout" that is aplied to every element you want to interact with (using findElement()) before throwing an exception, even the page is completly loaded or not.
Have a look to official doc.

How to make xpath work with Selenium when filepicker.io is loaded

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.
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:
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).
Use Implicit wait. That will always wait for an element if it's not found.
driver.manage().timeouts().implicitlyWait(5, TimeUnit.SECONDS);
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")));
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.