Watir should automatically scroll to an element before taking an action on
it. Sometimes there is more complicated javascript interactions required,
for which case I recommend using: https://github.com/p0deje/watir-scroll

On Mon, Oct 3, 2016 at 12:14 PM, <[email protected]> wrote:

> My page is not available for outside. My problem is, My page is very long
> so half of the page is visible and to see the other half, I need to scroll
> the page, So Once I have completed the first half, all the elements which
> are available in the rest of half, I need to scroll for each and every
> element. Why would I need to do that? In that case, it would be better if
> watir does two Jobs, One is to scroll the page and another is to enter the
> value or click the button,right?
>
> It's like, when watir-classic moves the text_field into focus before it
> fills the value, the following code does the job,
>
>          @o.focus(0)
>           @o.select(0)
>           dispatch_event("onSelect")
>           dispatch_event("onKeyPress")
>           @o.value = ""
>           type_by_character(value)
>
> Look at the first line @o.focus(0) moves the page and bring the text_field
> into focus. So if you think, it's important that element has to be visible
> to interact, then you could do something like this, right? Why would user
> has to do that Job every time? It's highly annoying, it's completely
> useless from the level of user.  I know this is not the restriction from
> watir-webdriver but it's from webdriver, but why not watir-webdriver has to
> implement this facility for the user?
>
>
>
> On Monday, October 3, 2016 at 10:32:08 PM UTC+5:30, Titus Fortner wrote:
>>
>> Why are you trying to click on something that a user can not click? If
>> you are doing what a user can do, you should not have any problems. Do you
>> have sample site/code that reproduces your concern?
>>
>> On Mon, Oct 3, 2016 at 11:42 AM, <[email protected]> wrote:
>>
>>> Is it important to maintain some kind of rule or to ease the user who
>>> automate the page? Which one is important? I am not the only one who
>>> reports this problem, there are many others who automated in watir-classic
>>> in the past has reported the same. If you still want to insist this
>>> restriction, then why do you give to the user? Why can't you establish the
>>> same feature within watir-webdriver? that means, when I try to click the
>>> element, let watir-webdriver itself bring that element into the visibility,
>>> So it resemble to the user level interaction,right?
>>>
>>>
>>> On Monday, October 3, 2016 at 9:48:03 PM UTC+5:30, Titus Fortner wrote:
>>>>
>>>> Watir is there to represent what a user can do on a page. If your
>>>> elements are not visible, your user can't interact with them, so your test
>>>> should not be able to interact with them. That's a feature. :)
>>>>
>>>>
>>>>
>>>> On Monday, October 3, 2016 at 7:33:57 AM UTC-5, [email protected]
>>>> wrote:
>>>>>
>>>>> Yes, that's why watir-webdriver is highly annoying, In watir-classic
>>>>> you don't find any such limitation, you can attach browser and you can
>>>>> click the element without doing the visibility checking, but in
>>>>> watir-webdriver we have to do separate coding to bring the element into
>>>>> visibility. I know this is not from watir-webdriver, it's from webdriver,
>>>>> but also whichever automation tool lies on this webdriver has to face this
>>>>> limitation, but the question is, Since it's a limitation, why not
>>>>> watir-webdriver does this job on behalf of user? Why not it brings the
>>>>> element into visibility when I tend to press the button? For an example, 
>>>>> if
>>>>> you enter a text in the text_field, it automatically brings the text_field
>>>>> into visiblity because of the focus function, Said that, why not the same
>>>>> function can be given to all the elements which user tend to interact?
>>>>>
>>>>> On Monday, October 3, 2016 at 2:42:05 AM UTC+5:30, Titus Fortner wrote:
>>>>>>
>>>>>> Hi Stephano,
>>>>>>
>>>>>> No, the w3c standard has no notion of being able to attach to an
>>>>>> existing browser:  https://w3c.github.io/webdriv
>>>>>> er/webdriver-spec.html
>>>>>>
>>>>>> Additionally, Internet Explorer support is eventually going to go
>>>>>> away in favor of Edge (which Microsoft itself is writing the driver for).
>>>>>>
>>>>>> The best alternative I can suggest is to use debugging tools like
>>>>>> pry, or RubyMine's excellent debugging options.
>>>>>>
>>>>>> Titus
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Sunday, October 2, 2016 at 3:50:38 PM UTC-5, Stefano wrote:
>>>>>>>
>>>>>>> Hi, yes I know that there is not such method in WATIR-Webdriver to
>>>>>>> attach the browser as we do in WATIR-classic. Actually, it is not a 
>>>>>>> matter
>>>>>>> opening a new browser, but the big problem is how restore the session 
>>>>>>> state
>>>>>>> of the web application when the test has been interrupted (maybe for a
>>>>>>> misconfiguration, an errore in the code of the watir script, etc)
>>>>>>>
>>>>>>> This situation is normal during debug or configuration of the
>>>>>>> scripts. For our application, to repeat a test from de beginning is 
>>>>>>> crazy -
>>>>>>> it can take several minutes each time to reach the same state a script 
>>>>>>> was
>>>>>>> interrupted starting from the beginning.
>>>>>>>
>>>>>>> We need, in some way, to be able to continue a test from the same
>>>>>>> test it was interrupted, even if in a new browser. How we can do it?
>>>>>>>
>>>>>>> Thanks al lot,
>>>>>>> Stefano
>>>>>>>
>>>>>>> 2016-10-02 11:03 GMT+02:00 <[email protected]>:
>>>>>>>
>>>>>>>> Hi stefano,
>>>>>>>>
>>>>>>>> There is no such method in WATIR-Webdriver to attach the browser as
>>>>>>>> we do in WATIR-classic. If you want to do it, you need to open a new
>>>>>>>> browser.
>>>>>>>>
>>>>>>>> On Thursday, September 29, 2016 at 2:17:39 PM UTC+5:30, Stefano
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Hi all,
>>>>>>>>>
>>>>>>>>> we are approaching the gradual conversion of all ours test cases
>>>>>>>>> from watir-classic to watir-webdriver.
>>>>>>>>>
>>>>>>>>> For the moment, there are not big problems both for the update of
>>>>>>>>> Ruby scripts and about stability of the scripts themselves
>>>>>>>>>
>>>>>>>>> However we have a big concern, that we have not solved yet, also
>>>>>>>>> searching on the net.
>>>>>>>>>
>>>>>>>>> The old method "attach", available with watir-classic, was very
>>>>>>>>> useful during debug or configuration of the scripts.
>>>>>>>>>
>>>>>>>>> Do you know if there exist an similar way to do the same of
>>>>>>>>> "attach" with watir-webdriver? Will it foreseen a similar method 
>>>>>>>>> "attach"
>>>>>>>>> with watir-webdriver?
>>>>>>>>>
>>>>>>>>> Thanks all,
>>>>>>>>> Stefano
>>>>>>>>>
>>>>>>>>>
>>>>>>> --
>>> --
>>> 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.
>

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