No, it does not make sense to do that kind of workaround to a basic
WebDriver call. A website that refreshes when making a clear call to a text
field sounds like a nightmare to test, but that one is on whoever decided
that could possibly be a good website design choice. :)

What we might be willing to do is to provide a command that will enter text
by JavaScript. I'm curious if that would solve your problem.

On Sun, Mar 26, 2017 at 12:32 PM, Raja gopalan <[email protected]>
wrote:

> I completely agree, WATIR does it's extraordinary performance in the case
> of stale element reference error, the only reason is because it continue to
> invoke the find_element until it finds the element and I know that's the
> reason WATIR avoids implicit wait. That's excellent. But you are not caring
> certain places which falls into the infinite loop which I explained
> earlier, For an example,
>
> Consider this following code
>
> def set(*args)
>  element_call(:wait_for_writable) do
>  @element.clear
>  @element.send_keys(*args)
>  end
> end
>
>
> What my application does is, it refreshes the page after the clearing the
> element, So after @element.clear,( since page got refreshed), @element
> object is stale now, So @element.send_keys throws the error but it's been
> caught by the given block below
>
> begin
>  send exist_check
>  yield
> rescue Selenium::WebDriver::Error::StaleElementReferenceError
>  retry
> ensure
>  Wait.timer.reset! unless already_locked
> end
>
> So it is retrying, but what happens is, once again it starts from the
> beginning, So when it executes @element.clear, it once again goes to stale
> state, So it falls into the infinite loop and it never comes out. So what
> you would have done here is,
>
> you could have written the code like given below
>
> def set(*args)
>  element_call(:wait_for_writable) do
>  @element.send_keys([:control,"a"],*args)
>  end
> end
>
>
> Now the problem solved because choosing the entire cell content and then 
> writing on it automatically does the clearing Job. So the element doesn't go 
> stale in this case.
>
>
>
>
> On Friday, March 24, 2017 at 12:25:36 PM UTC-7, Titus Fortner wrote:
>>
>> Yes, Watir is slower. Think of Selenium as a "Do What I Say" tool. If you
>> can enumerate exactly what you need using its low level commands then you
>> can be very performant. Watir is a "Do What I Mean" tool. Watir's goal is
>> not speed, but ease of writing, ease of maintenance, consistency of
>> results, and usefulness of error messages for debugging.
>>
>> There are many advantages to using Watir over Selenium directly which I
>> need to spend time enumerating in a blog post at some point, but the two
>> most important things that Watir does right now is automatically handle
>> Stale Element Reference errors (the bane of many test automation suites),
>> and automatically wait for the site's condition to be synchronized with
>> what is expected of the test based on the Watir code. There are many other
>> conveniences that may not always be needed but are provided by default so
>> that no user has to do extra work to handle it when it is necessary.
>>
>> Watir can slow things down a little or a lot depending on what you are
>> trying to do. I have some ideas to increase performance in some situations,
>> but again, my focus is primarily on making it easy for people who don't
>> know all the details of their website's implementation to get consistent
>> results.
>>
>> Titus
>>
>>
>> On Thursday, March 23, 2017 at 12:16:00 PM UTC-5, Raja gopalan wrote:
>>>
>>> Titus, I stongly believe checking enabled? present? writable? methods
>>> are unnecessary calls by WATIR because we know what kind of field we are
>>> going to interact so these calls to every element slows down the process So
>>> what I did was, I have CALLED the driver out of WATIR and started writing
>>> selenium code and wherever I want the help of WATIR help like
>>> b.table.rows.each, I will write watir code and also If I know there are
>>> certain element starts to appear after the click then I write watir code,
>>> So I am mixing the selenium code and WATIR code as shown below,
>>>
>>> For an example, look at the code below and see how I have mixed the
>>> selenium code and WATIR CODE
>>>
>>> require 'watir'
>>>
>>> class Cable
>>>
>>>   def initialize
>>>     caps = Selenium::WebDriver::Remote::Capabilities.firefox(marionette: 
>>> false)
>>>     @b=Watir::Browser.new :firefox, desired_capabilities: caps
>>>     @b.goto 'smcnet.in/'
>>>     @[email protected]
>>>   end
>>>
>>>   def call
>>>     @driver.find_element(:id, 'username').send_keys 'raja'
>>>     @driver.find_element(:id, 'password').send_keys ''
>>>     @driver.find_element(:xpath, "//*[@value='Log In']").click
>>>     @driver.find_element(link: 'My Plan').click
>>>     @b.element(xpath: "//span[normalize-space(.)='usage details']").click   
>>>  # WATIR CODE
>>>     puts @b.div(:text, 'MB Used').following_sibling.span.text               
>>>  # WATIR CODE
>>>     puts @b.div(:text, 'Days Remaining').following_sibling.span.text        
>>>  # WATIR CODE
>>>     @driver.find_element(link: 'Hi, RAJAGOPALAN M').click
>>>     @driver.find_element(:xpath, '//li[3]/a').click
>>>     # @driver.quit
>>>   end
>>> end
>>>
>>>
>>> On Thursday, March 23, 2017 at 10:06:26 AM UTC-7, Titus Fortner wrote:
>>>>
>>>> Yes, #present? is a combination of #exists? and #visible?
>>>>
>>>> Also, with Watir 6, you are less likely to need to make this call
>>>> explicitly in the code. Taking actions on an element will automatically
>>>> wait for element to be present if necessary.
>>>>
>>> --
> --
> Before posting, please read http://watir.com/support. In short: search
> before you ask, be nice.
>
> [email protected]
> http://groups.google.com/group/watir-general
> [email protected]
>
> ---
> You received this message because you are subscribed to the Google Groups
> "Watir General" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> For more options, visit https://groups.google.com/d/optout.
>

-- 
-- 
Before posting, please read http://watir.com/support. In short: search before 
you ask, be nice.

[email protected]
http://groups.google.com/group/watir-general
[email protected]

--- 
You received this message because you are subscribed to the Google Groups 
"Watir General" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to