Yeah, that would be good idea. Our waiting methodology is what we differ
tremendously from directly using Selenium. When they use this driver level
wait, that would hinder WATIR to do its job as expected.
On Wed 8 Aug, 2018, 12:14 PM Titus Fortner, wrote:
> Oh wow, implicit_wait of 300 will like
Oh wow, implicit_wait of 300 will likely cause issues even if you aren't
using Watir. Definitely don't need it with Watir. I kind of want to change
the Selenium code to expose the existing implicit wait value in the driver
just so Watir can check for it and throw big warning flags saying not to
Hi you don't have to use implicit wait while you use WATIR , that's needed
if you use pure selenium binding. If you use implicit wait, then you can't
know the element status immediately. Don't use implicit wait, WATIR has its
own waiting strategy.
On Wed 8 Aug, 2018, 11:16 AM NaviHan, wrote:
> H
Hi Titus and Justin
"wait_for_ajax" did the job :-) I used it only at places where the spinner
loading caused problem. Im curios where to put the code blok Titus provided
in the hooks.rb file
My hooks look like this.
@Justin, Im curios to know why you asked if Im sure that the timing issue
was
Okay it clearly make sense. Thanks.
On Wed 8 Aug, 2018, 12:29 AM Titus Fortner, wrote:
> Whether you use or don't use the block should be independent of whether
> you want to close the window.
>
> b.window(title: /foo/).use do
> do_things
> end
>
> is the exact same thing as
>
> b.window(title
Whether you use or don't use the block should be independent of whether you
want to close the window.
b.window(title: /foo/).use do
do_things
end
is the exact same thing as
b.window(title: /foo/).use
do_things
b.original_window.use
I avoid doing things by block whenever possible, and this ex
If you block while you are switching to the new window then it has to close
while we are coming out of the block.
If we don't want close, then we should not be using the block.
Yes? Or is it not a good idea?
On Wed 8 Aug, 2018, 12:09 AM Titus Fortner, wrote:
> I'm lost on what your question is
I'm lost on what your question is.
On Tuesday, August 7, 2018 at 11:30:00 AM UTC-7, rajagopalan madasami wrote:
>
> Hi sorry once again, please read this.
>
>
> If I want to switch the window again I should not using block. I need to
> use the way you are using without block
>
> On Tue 7 Aug,
Hi sorry once again, please read this.
If I want to switch the window again I should not using block. I need to
use the way you are using without block
On Tue 7 Aug, 2018, 11:54 PM Titus Fortner, wrote:
> What are you asking? The block should not close the window automatically,
> what if you w
Sorry for last mail, mistake in typing , please read here
If I want to switch the window again I should not using window. I need to
use the way you are using without block
On Tue 7 Aug, 2018, 11:54 PM Titus Fortner, wrote:
> What are you asking? The block should not close the window automatical
If I want to switch the window again I should not using window. I need to
use the way you are using without block.
On Tue 7 Aug, 2018, 11:54 PM Titus Fortner, wrote:
> What are you asking? The block should not close the window automatically,
> what if you want to switch to it again?
>
>
>
> On T
I have already read this thread , thank you.
On Tue 7 Aug, 2018, 11:44 PM Titus Fortner, wrote:
> The poc code for Watir::Executor has been sitting in the PRs for a year:
> https://github.com/watir/watir/pull/587
>
> I was going to wait until Watir 7 to release it, but I don't think there
> is a
What are you asking? The block should not close the window automatically,
what if you want to switch to it again?
On Tuesday, August 7, 2018 at 11:17:45 AM UTC-7, rajagopalan madasami wrote:
>
> >>Ah, this got lost in the business that is Watir General this week<<
>
> I didn't understand this l
>>Ah, this got lost in the business that is Watir General this week<<
I didn't understand this line.
I know it switched back but the window which has switched left for no
reason ? When it comes to block it obviously has to close the window which
has been opened and switched. If you are not using
The poc code for Watir::Executor has been sitting in the PRs for a year:
https://github.com/watir/watir/pull/587
I was going to wait until Watir 7 to release it, but I don't think there is
anything backward-compatibility breaking in it, so I don't think I should
technically need to wait for that.
Ah, this got lost in the business that is Watir General this week
If you are using the block it will automatically switch back to the
original window for you.
I don't like using blocks for things like this, so I explicitly switch back
using `#original_window`.
Neither approach automatically clo
Hi here you forgot to reply my previous mail. When I use block when
switching to the window , it's automatically needs to close the window, eh?
Please see my previous mail as well.
On Tue 7 Aug, 2018, 8:56 PM Titus Fortner, wrote:
> Oh no, I gave the right code: https://stackoverflow.com/a/51666
I have created a framework where I specifically asked them to use click and
clickAndWait separately , click will simply performs the WATIR click,
clickAndWait will perform the WATIR click and call the function waitForLoad
as you have seen. So if such a hook is available that would be easy for me.
It's more than that when running remotely, though. Definitely use it if it
makes sense regardless of local or remote, but if you've solved your issue
by just wrapping the select method, that's targeted and "better." :)
On Tuesday, August 7, 2018 at 10:41:36 AM UTC-7, Justin Ko wrote:
>
> I agr
Ah that's very negligible! I believe I can add that in my current project.
On Tue 7 Aug, 2018, 11:11 PM Justin Ko, wrote:
> I agree that adding it to the after hooks adds overhead. Though at 0.015s
> per click, it's not the worst thing in the world.
>
> I worked on one application where almost e
Hey Charley, I got a huge dump of info from Jonathan Kohl from the
early days. If you have anything you'd like to see added, send me a
few paragraphs and I'll see about getting it all synthesized together.
On Tue, Aug 7, 2018 at 10:34 AM Charley Baker wrote:
>
> Hah pretty cool. I remember back in
I agree that adding it to the after hooks adds overhead. Though at 0.015s
per click, it's not the worst thing in the world.
I worked on one application where almost every button/link click triggered
a loading overlay. Creating a method for each button/link to add the wait
would defeat the purp
HI Thanks for sharing this article. Please share here whenever you write a
new article, Thanks.
On Tuesday, August 7, 2018 at 12:07:41 AM UTC+5:30, Titus Fortner wrote:
>
> I just posted an article on the History of the Watir project.
>
> http://watir.com/history/
>
> Titus
>
--
--
Before
Hah pretty cool. I remember back in the day. It's been a while since I was
involved. There's a lot more history, but ya can't get it all. :)
Cheers,
Charley
On Mon, Aug 6, 2018 at 12:37 PM Titus Fortner
wrote:
> I just posted an article on the History of the Watir project.
>
> http://watir.co
Hi Titus,
Can you please look at this problem, This guy is using selenium Ruby
Binding directly, I suggested him using WATIR instead. He is facing some
issue while initialing with WATIR!
https://stackoverflow.com/questions/51725080/issue-with-attempting-to-run-a-test-using-chromedriver
On
Okay, I will be waiting for that then! There was a new project in my
company for which I convinced them to use WATIR instead of Selenium where I
had to implement this waiting behavior! Okay excited to see this new
feature to be added! Thanks.
On Tuesday, August 7, 2018 at 10:24:55 PM UTC+5:30
you'll be able to specify the exact desired behaviours in a more granular
way
On Tue, Aug 7, 2018, 9:53 AM wrote:
> Oh okay. But you said
>
> The Executor class when implemented will open up a lot more flexibility.
>
>
> So will it be lesser wire call after Executor class implemented? Can I add
Oh okay. But you said
The Executor class when implemented will open up a lot more flexibility.
So will it be lesser wire call after Executor class implemented? Can I add
after that?
On Tuesday, August 7, 2018 at 10:18:51 PM UTC+5:30, Titus Fortner wrote:
>
> No, your way is better if it is
No, your way is better if it is working for you. Adding it to the after
hook will add a ton more unnecessary calls to your code.
On Tue, Aug 7, 2018 at 9:38 AM wrote:
> That will be interesting, I am using as shown below,
>
>>
>> def selectAndWait(locator, value)
>> select locator, value
>>
That will be interesting, I am using as shown below,
>
> def selectAndWait(locator, value)
> select locator, value
> waitForPageLoad
> end
>
> def waitForPageLoad
> @b.wait_until(timeout: @Page_Load) {@b.execute_script("return
> (jQuery.active === 0)").eql? true}
> end
>
>
Let me try usin
Hi Titus,
don't you think when you use the block to switch to the new window, it has
to close while it comes out?
>
> require 'watir'
> driver = Selenium::WebDriver.for :chrome
> b = Watir::Browser.new driver
>
> b.goto 'https://services.wiltshire.gov.uk/PlanningGIS/LLPG/WeeklyList'
>
> b.select
after any action that changes or is likely to change the dom, so it can get
heavy if overused. The Executor class when implemented will open up a lot
more flexibility.
On Tue, Aug 7, 2018, 9:27 AM wrote:
> Ah! that's pretty interesting, I was not knowing this. So you say Once I
> have written
Ah! that's pretty interesting, I was not knowing this. So you say Once I
have written this code, this code will be executed after every click I do?
On Tuesday, August 7, 2018 at 9:54:17 PM UTC+5:30, Titus Fortner wrote:
>
> jquery_wait = lambda { |br| br.wait_until { |b| b.execute_script('return
jquery_wait = lambda { |br| br.wait_until { |b| b.execute_script('return
jQuery.active == 0') } } browser.after_hooks.add(jquery_wait)
On Tuesday, August 7, 2018 at 9:17:32 AM UTC-7, rajagopal...@gmail.com
wrote:
>
> Hi Justin,
>
> We are also using this wait_for_ajax in one of our Project. Yo
Hi Justin,
We are also using this wait_for_ajax in one of our Project. You said
I would suggest adding the jQuery.active check to your browser's
> after_hooks. Ideally this would catch all (or at least most) of the
> problems.
>
May I know how to do this?
On Tuesday, August 7, 2018 at 9:3
A! Okay, Got it! Thank you Very much!
On Tuesday, August 7, 2018 at 8:56:29 PM UTC+5:30, Titus Fortner wrote:
>
> Oh no, I gave the right code: https://stackoverflow.com/a/51666596/4072371
>
> Also, original_window is stored for you, you don't need to create it.
>
> b.select_list(id: 'selWe
The #wait_for_ajax simplifies things if you need to manually call it.
However, it sounds like you would have to sprinkle this everywhere.
I would suggest adding the jQuery.active check to your browser's
after_hooks. Ideally this would catch all (or at least most) of the
problems.
Note that the
Found it
See the section on Waiting for AJAX Calls here:
http://cheezyworld.com/2012/02/23/page-object-0-6-2-released/
let's you call `wait_for_ajax` where you want it.
On Tue, Aug 7, 2018 at 7:43 AM NaviHan wrote:
>
> Yes Justin, That was exactly what happened. I ran the script a few times and
Oh no, I gave the right code: https://stackoverflow.com/a/51666596/4072371
Also, original_window is stored for you, you don't need to create it.
b.select_list(id: 'selWeek').options.each do |option|
option.select
b.button(id: 'csbtnSearch').click(:control)
b.windows.last.use
p b.element(x
Gah, I mixed in Selenium code.
In Selenium `driver.close` closes the window, and `driver.quit` ends
the session.
In Watir it needs to be `b.window.close`
Let me find the SO entry to fix it.
On Tue, Aug 7, 2018 at 4:05 AM wrote:
>
> Hi Titus,
>
> We have recently had the talk in Stackoverflow, wh
Yes Justin, That was exactly what happened. I ran the script a few times
and using "Watir::Wait.until(timeout: 30) {@browser.execute_script('return
jQuery.active == 0')}" never gave me the error "
Element ... *is not clickable* at
point (537, 362). Other element would receive the click: *"
T
Hi Navi,
Just to be clear, are you saying that "Watir::Wait.until(timeout: 30) {
@browser.execute_script('return jQuery.active == 0')}" solves the timing
issue? You are just asking if there is a Page Object way to avoid doing
this manually everywhere?
Thanks,
Justin
On Tuesday, August 7, 2018
Hi Titus
I found a good deal of documentation from PageObject wiki so was able to
substitue the waits with PageObject equivalent.
https://github.com/cheezy/page-object/wiki/Ajax-Calls
Still the issue with spinner(Loader.bg) holds and Im working this around
using "Watir::Wait.until(timeout: 30)
Hi Titus,
We have recently had the talk in Stackoverflow, where you have suggested me
this code
I tried using your code but when I reach b.close, it's closing the browser
totally not the tab which has opened recently so I couldn't connect to the
original window.
Please execute this code
req
Yes Titus. I actually meant click after the wait.
The stale element issue is resolved with Watir upgrade.
I used jquery statement and managed to fix the issue. But what is the page
object way to do that?
Also could you please clarify the difference between wait.until(&:present?) and
wait.wh
45 matches
Mail list logo
