Hi Titus, yeah you are right, I checked with stack over flow site, yes,
it's loading to that element in which I tend to click. So I guess, there
might be some other reason why my page is not scrolling up when the
intended element needed to be clicked.
Thanks,
Gopal.
On Monday, October 3,
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, wrote:
> My
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
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, wrote:
> Is it important to maintain
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,
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, rajagopa...@gmail.com wrote:
>
> Yes,
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
Yes, this is what I keep telling here and stack overflow as well. That idea
seems to be good,but in practical, it creates too much trouble.
On Monday, October 3, 2016 at 1:45:21 PM UTC+5:30, Stefano wrote:
>
> Thank Titus for your answer.
>
> From the point of view of the developer of watir
Thank Titus for your answer.
>From the point of view of the developer of watir script ok, I agree with
you.
However, from user's point of view (who actually configure a automatic test
case or has to correct the configuration becouse of changes in business
data) is a big problem. For example,
Hi Stephano,
No, the w3c standard has no notion of being able to attach to an existing
browser: https://w3c.github.io/webdriver/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
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
Actually you can. And without any problem through usual
browser.window(:title=Browser title).use do
code
end
or even to sub-window
browser.window(:title=Browser title).use do
code
browser.window(:title=Browser title).use do
code
browser.window(:title=Browser title).use do
code
The Watir::IE.attach class method has not moved. it's still in the same
place
FireWatir::FireFox.#attach instance method has not moved. it's still in the
same place.
Browser.#attach module method does not exist yet.
Bret has an attach branch of code if you want to investigate it
aidy lewis wrote:
Hi,
Can anyone tell me where the attach method now exists?
Aidy
It is an instance method on Watir::IE and a class method on
FireWatir::Firefox.
If you look in trunk, you'll see that there is also an instance method
on FireWatir::Firefox.
Bret
14 matches
Mail list logo