Thank you very much..What is that 1 mean to ?Is that mean 1 sec? On Monday, 24 April 2017 20:03:00 UTC+5:30, [email protected] wrote: > > Hi Raja, > > It's documented here: > http://www.gebish.org/manual/current/#page-level-at-check-waiting > > In a pinch, either in your spec or in GebConfig, you can simply do: > > atCheckWaiting = 1 > > On Thursday, April 13, 2017 at 5:16:43 PM UTC+1, Raja Rajan wrote: >> >> Erdy , >> How do we configure atCheckWaiting configuration to one second , as you >> mentioned.Please help >> >> >> On Thursday, 7 April 2016 19:23:06 UTC+5:30, Marcin Erdmann wrote: >>> >>> Hi Andrey, >>> >>> What you're seeing is most probably down to performance improvements in >>> Geb which were introduced in 0.12.x and 0.13.x and which boil down to Geb >>> not executing some unnecessary commands that it did in the past. I can >>> point you to issues and commits that relate to that if you want me to. >>> >>> What adds to the situation you're facing is the fact that Firefox driver >>> has historically been flakey when it comes to waiting for the page to load >>> - it should wait until any callbacks registered on page load execute but it >>> doesn't sometimes it will return control even before any html is loaded. To >>> aid that at some point we introduced the atCheckWaiting config option ( >>> http://www.gebish.org/manual/current/#at-check-waiting). I would >>> suggest you configure it to wait for up to a second if you're using Firefox >>> as your driver. We are at my current project and without it we would almost >>> always have a test that fails when switching pages and running at checkers. >>> >>> A solution to your other issue would be to model your pop ups as pages >>> with at checkers and use the page option of withNewWindow() method ( >>> http://www.gebish.org/manual/current/#code-page-code-2). Having >>> atCheckWaiting enabled as well would mean that the Geb would ensure that >>> the page has loaded in the new window before handing control back to the >>> closure you pass as the last argument in your withNewWindowCalls. >>> >>> So to confirm - this is not a bug in Geb as Geb always interacts with >>> the browser via WebDriver and this includes navigating to urls. It's just >>> that making Geb this bit faster exposed situations where WebDriver >>> implementations should wait for the page to load but they don't. I >>> understand that this might be painful but this is how it is, we shouldn't >>> be slowing things down to avoid timing issues like that. >>> >>> It might seem like a lot of work to upgrade and fix the issues you're >>> seeing but I would advise you to do so if only you can afford the time. You >>> might hit a blocking issue one day which will mean that you will be forced >>> to upgrade over many versions at the worst possible moment and it will take >>> more time the longer you wait. I've learned that being on the latest >>> versions of your core tools always pays off. >>> >>> Marcin >>> >>> On Thu, Apr 7, 2016 at 11:52 AM, Andrey Hitrin <[email protected]> >>> wrote: >>> >>>> Even more, sometimes tests fail even on moving to another page: >>>> >>>> $('a', text: 'click me').click(NextPage) >>>> >>>> Works perfect in Geb 0.10.0, but in 0.13.1 it may cause >>>> UnexpectedPageException: >>>> >>>> geb.error.UnexpectedPageException: At checker page verification failed >>>> for page blah.meh.NextPage >>>> at geb.navigator.NonEmptyNavigator.click(NonEmptyNavigator.groovy:492) >>>> >>>> at geb.navigator.NonEmptyNavigator.click(NonEmptyNavigator.groovy:469) >>>> at ... >>>> >>>> Meanwhile error screenshot shows us that we're on the NextPage, as >>>> expected. >>>> >>>> четверг, 7 апреля 2016 г., 15:39:40 UTC+5 пользователь Andrey Hitrin >>>> написал: >>>>> >>>>> Hi! >>>>> >>>>> In our company we have a reasonably large suite of acceptance tests >>>>> (several hundred tests) written in Geb. Currently, we're using *Geb >>>>> 0.10.0*, Selenium 2.46.0 and Firefox (both local and remote). >>>>> >>>>> The problem appears when we try to upgrade our dependencies. Namely, I >>>>> try to upgrade Geb to the newest *0.13.1* without touching other >>>>> dependencies. >>>>> >>>>> It looks like WebDriver starts to act way more eager than before, >>>>> throwing away some previously existing waits. This causes our tests to >>>>> fail >>>>> in many random places unless we put a lot of *waitFor* into it. For >>>>> example, when working with dialogs: >>>>> >>>>> // Works fine with Geb 0.10.0, but not in the any newer version >>>>> browser.withNewWindow({ someButton.click() }) { >>>>> $('input#title').value(title) >>>>> ... >>>>> } >>>>> >>>>> >>>>> After upgrading to the newer versions this code may fail because >>>>> WebDriver may start to act on the dialog before page actually loads. When >>>>> I >>>>> put simple *assert !$('body').empty* into the beggining of the window >>>>> closure, it fails randomly (but never fails in Geb 0.10.0). So, in order >>>>> to >>>>> fix our tests we have to add a lot of waits, like that one: >>>>> >>>>> browser.withNewWindow({ someButton.click() }) { >>>>> waitFor { $('input#title').displayed } // or, for example, >>>>> waitFor{ !$('body').empty } >>>>> $('input#title').value(title) >>>>> ... >>>>> } >>>>> >>>>> But we have *a lot* of dialogs in our system under test, so amount of >>>>> code to change is really large. That's pity. >>>>> >>>>> Situation is a little more strange because I cannot reproduce this >>>>> problem *in virto*. When I just save HTML page of our application and >>>>> run it under Python SimpleHTTPServer, synchronisation issue on the dialog >>>>> disappears. But in our application (Spring web app running under Tomcat) >>>>> such failures appear very frequently. >>>>> >>>>> Seems like we have to stay on 0.10.0 for now, but it's unclear for me >>>>> whether the situation with waits will change in future. It's also unclear >>>>> whether it's a bug of Geb or not. >>>>> >>>>> May I ask you for help? >>>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "Geb User Mailing List" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> To post to this group, send email to [email protected]. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/geb-user/dba3e2bb-a38b-481f-b416-dca739660ae5%40googlegroups.com >>>> >>>> <https://groups.google.com/d/msgid/geb-user/dba3e2bb-a38b-481f-b416-dca739660ae5%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>>
-- You received this message because you are subscribed to the Google Groups "Geb User Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/geb-user/72136705-677c-4295-83a4-f5ee23de87d4%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
