> 3. The click is sent to the coordinates, which since the button has since moved, will not click the button
If this happened, there should be a stale element exception, which Watir would continue to relocate until it worked, which is why I suspect it is JS element/action binding related, which means the fire event theoretically wouldn't do anything differently. Dynamically waiting for an element to stop moving is kind of cool... Hadn't considered that approach before. On Tuesday, September 25, 2018 at 8:37:53 AM UTC-7, Justin Ko wrote: > > (Sorry, if some of this repeats Titus's response. I was half way through > this when he replied.) > > If I'm envisioning the sliding correctly, I believe what happens is: > 1. The button starts sliding on to the page (at which point it'll be > considered present) > 2. The coordinates of the button are retrieved, however this will be some > point along the slide path (rather than the final destination) > 3. The click is sent to the coordinates, which since the button has since > moved, will not click the button > 4. The button reaches it's final destination > > Ideally, you would find something that indicates that the animation has > completed. I was recently told that jQuery has some property to check for > its animations. You could see if there is something similar in your > application. Waiting on this would likely be the most robust approach. > > The quickest solution, would be to directly fire the click event, without > worrying about click coordinates. This would make the script less like a > user, but might be acceptable. > > def continue_as_guest > continue_as_guest_element.fire_event(:onclick) > end > > If you want to maintain the more user-like behaviour, you could wait for > the button to reach it's final destination before doing the click. If final > destination is known, you could do: > > def continue_as_guest > btn = continue_as_guest_element > btn.wait_until do |btn| > center = btn.center > center.x == 464 && center.y == 173 # using your expected coordinates > end > btn.click > end > > If you don't know the exact destination, you could do some polling: > > def continue_as_guest > btn = continue_as_guest_element > initial_center = btn.center > btn.wait_until do |btn| > sleep(1) # assuming the animation moves fast enough > new_center = btn.center > initial_center.x == new_center.x && new_center.y == new_center.y > end > btn.click > end > > Justin > > On Tuesday, September 25, 2018 at 11:30:48 AM UTC-4, Titus Fortner wrote: >> >> This kind of dynamic code is difficult. >> >> Firstly, `wait_until(&:present?).click` is currently redundant. The wait >> will happen automatically if you just do: `click` >> >> Essentially the driver is processing the element as displayed before the >> desired action is attached to that element. Ideally, the front end devs >> add classes that indicate the status of the transitions that can be polled >> specifically before acting. >> >> If this is being done through a specific JS framework (like jQuery or >> Angular), you can do a generic wait for that framework's activity to be >> complete (see watir_angular gem or PageObject's JavascriptFrameworkFacade >> for JQuery) >> >> The final and hackiest approach I have used in the past is to implement >> an `#ensure_click` method where you specify the condition that has to be >> met for the click to be successful, and re-click if it is not. But this is >> inherently tricky because of all the race conditions possible. >> >> >> >> On Monday, September 24, 2018 at 9:41:15 PM UTC-7, NaviHan wrote: >>> >>> Its been some days I found this issue untill I understood today the >>> cause of failure. >>> >>> The behavior is >>> a. The user enters the email on check out page >>> b. A pop up skids in from the top of the page >>> c. The user clicks a "continue as guest "button on the pop up >>> d. The pop up skids back in and disappears >>> e. Verify the pop up disappeared >>> >>> The issue is between step b and step c there is a time when the pop up >>> is sliding into the page until its loaded completely. During this time the >>> script clicks the dismiss button. Because the pop hasent completed loading >>> the click doesn't make it disappear. >>> >>> Similarly becasue the pop up takes time to slide back and disapper the >>> check at step e fails. >>> >>> For the time being Im working around this issue with sleeps. But is >>> there a neater way? >>> >>> >>> The pop up is defined as >>> >>> button(:continue_as_guest, :class => ['button', 'close-dialog-button']) >>> >>> >>> The code that does the job is >>> >>> def continue_as_guest >>> continue_as_guest_element.wait_until(&:present?).click >>> end >>> >>> >>> After sleep, which works fine >>> >>> def continue_as_guest >>> sleep 5 >>> continue_as_guest_element.wait_until(&:present?).click >>> sleep 5 >>> end >>> >>> >>> Note:- I have also tried to wait_while(&:present?) still the issue stays >>> the same >>> >>> def continue_as_guest >>> >>> continue_as_guest_element.wait_until(&:present?).tap(&:click).wait_while(&:present?) >>> end >>> >>> >>> >>> -- -- Before posting, please read https://github.com/watir/watir_meta/wiki/Guidelines-for-Posting-to-Watir-General-Google-Group. In short: search before you ask, be nice. watir-general@googlegroups.com http://groups.google.com/group/watir-general watir-general+unsubscr...@googlegroups.com --- 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 watir-general+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
