I am running a test on a web app using Ruby-Watir-Rspec. It is very simple since I'm a beginner.
I open a form and enter the required information, but the "Create" button is not in the visible area, so I get the message:
Failure/Error: #browser.button(class: xxx).click
Watir::Exception::UnknownObjectException:
element located, but timed out after 30 seconds, waiting for #<Watir::Button: located: true; {:class=>xxx, :tag_name=>"button"}> to be present
Caused by:
# Selenium::WebDriver::Error::ElementNotVisibleError:
# element not interactable
If I scroll while the script is running, it clicks on the button and the test is successful.
I tried scroll.to, wait_until_present, scroll to coordinates, scroll_into_view, none of them worked.
The only way to make it work was to put " #browser.send_keys :tab" several times until it reaches the button at the bottom of the form.
I believe the problem is the button being inside the form which does not take the entire page (behind the form is the map so that part of the page doesn't have the scrolling option)...so is there some way to scroll inside the form? Or do you know some other approach to finding this button? Any hint is appreciated.
Btw, the page is maximized.
Here is the code snippet, just simple:
it 'should create the place' do
#browser.button(class: xxx).click
end
My guess is that this is a custom scrollable element that hides the content with the overflow: hidden style. Elements in the overflow are not considered visible/present. When you manually scroll, you're bringing the element out of the overflow so that it's present.
I've seen a couple of these in the past. Each one needed a different approach for scrolling. Without the exact HTML/CSS, it's hard to say how to scroll the element.
However, if you're not trying to test the scrolling, you could manually fire the click event. This will bypass the visibility requirements:
#browser.button(class: xxx).click!
Try using the Watir Scroll gem: https://github.com/p0deje/watir-scroll and scrolling the element to the center of the viewport: button.scroll.to :center.
You can also submit the form directly #browser.form.submit
Related
Context: In my rspec (using Ruby and Capybara)
I click on a link to test an action in my app: adding a branch to my app.
A modal window opens, where I select the branch, and then I click a "submit" button to add the branch to my app. After clicking "submit" the modal window is closed.
The rspecs continues by clicking "Save" in the main screen, to save the state of the application (and effectively saving adding the branch).
Problem: The rspec is failing because (seemingly) it is trying to click the "Save" button on the main screen while the modal window that is used to select the branch is still present. The test doesn't complain that it can't find the "Save" button component, but that it can't be clicked.
The error in the log is:
[...]Save</button> is not clickable at point (692, 23). Other element would receive the click[...]
A gotcha: this rspec passes correctly on some environments, like when it is run against my local server, but it fails when it is executed by our automation server. Thus, this test has been tagged as "flaky".
Potential solutions: Things we have tried so far:
Play around our "clicks configuration", making sure we are on "ready state" and that the modal window is gone. We failed with this, since we kept hitting the same error.
Implement a "wait". We added a loop to sleep for a bit while the modal window seemed to exist
XYZ.add_new_branch_name(#branch_name)
while Utilities.element_visible?(:xpath, myElement)
sleep(0.5)
end
XYZ.save
The while condition checks if the "submit" button of the modal window exists. The element_visible function uses
find(method,element).visible?
but I'm not sure if find should already take into account that the button may exist and be visible but not be clickable.
Since this still fails, in spite of all our effort to make sure that the modal is gone before we attempt to click on the "save" button, I want tot ask:
Is there a proper way to detect if an element behind a modal window is clickable or not using rspecs?
find only cares about "visibility", not "clickability" (and different drivers may have slightly different interpretations of "visibility"). The reason for the flakiness you're seeing is most likely speed of the machine running the tests which affects the timing of the modal animating away. The best way to solve this issue is to disable animations in the test mode (how you do that is dependent on exactly what library and/or CSS you're using for the animations). The other way is to do as you're doing - checking that the modal has disappeared before clicking the 'Save' button, however you should just be using the Capybara provided methods (which include waiting/retrying behavior) rather than writing your own loop for that.
expect(page).not_to have_css('css selector of the modal') # RSpec version
assert_no_css('css selector of the modal') # minitest version
After looking at the mouse position from your error, one other potential issue you may be having is with screen size and scrolling. If the page requires to be scrolled to get to the 'Save' button and (692, 23) would put the button behind a fixed header (you should be able to verify that by taking a screenshot before the button click attempt) then it may not be possible for whatever driver you're using to click the button. In that case you'd need to use execute_script to scroll the page to a different location so the button is not covered on the page and/or increase the "browser" size so scrolling isn't necessary in the test.
I had a similar problem and solved it by writing my own click_on_with_wait helper function:
def click_on_with_wait(text, wait_time: Capybara.default_max_wait_time)
success = false
(wait_time * 10).round.times do
click_on text
success = true
break
rescue Selenium::WebDriver::Error::WebDriverError
sleep(0.1)
end
# Try clicking one last time, so that the error will get raised if it still doesn't work
click_on text unless success
end
This will try to click on the element. If it's still hidden by the modal, the function will wait 100ms and then try again, until the given wait_time is reached.
Using Rails, I put it in system_spec_helpers.rb so that I can simply replace click_on 'Submit Form' with click_on_with_wait 'Submit Form'.
I have a problem. While parsing a page, a pop-up window appears and blocks access to html. I tried to click on the pop-up, but it re-directs me to a new page, and I have no clue how to get to the upper right area of the pop-up to close it. My question is how to determine the coordinates of that element? None of the related issues raised here at Stackoverflow helped me find a solutions, so assistance would be very much appreciated.
Why do you need the actual coordinates? That seems like a bad idea given it could move or have different results on different screen sizes (responsive designs). You'd be better off finding the class / id of the close button and calling browser.button(class: 'close').click or browser.link(class: 'close').click.
If you need help determining the class of the close button, open your browser and enable developer tools / console. They all have an inspector tool now to select the element and find all classes & ids.
In the unlikely event there are no classes or ids it may have a data attribute you could work off.
If the pop-up is a regular browser window you can close it by index. Your main window has index 0. So the pop-up has index 1.
if browser.window(:index => 1).exists?
browser.window(:index => 1).close
end
I am using Selenium Webdriver(Ruby) to automate my web app and my web app has this carousel wherein my element continuously keeps moving in a loop.
By the time I locate that element and try to click it, element moves ahead.Hence I am not able to locate that element.
I tried finding and clicking that moving element by following code:
{
ele_button = driver.find_element(:xpath,"xpath")
sleep 10
ele_button.click
}
I thought that by 'sleep 10' I could make that element wait for 10 seconds and then click it.But this does not work and I am getting ElementNotVisibleError whenever I run my script.
Question:
Is it even possible to automate a moving element? If yes please provide me a solution.
Yes it is absolutely possible. I handled same scenario for carousel on my site. There are three ways:
Most carousel stop on mouse hover. So you may use it to stop the
carousel. Use Actions class to move over to the carousel. Once it
stops you may click on it.
If you want a specific slide, you can click on dots or any other navigator, like prev/nxt, to reach your slide and then click it.
The sure shot way to click your specific slide, without worrying about whether it is displayed or not is to use Javascript to click it (Which I had done in my case although I had also implemented 2nd way but I found javascript the simplest solution).
Why are the actions divided?
I would recommend the following:
driver.find_element(:xpath,"xpath").click()
so it will find the object and click on it.
Another thing you can do, as we doing in selenium with java that put the implicitlyWait according to the time on which your button came back after one rotation; now perform click just after implicitlyWait
driver.manage().timeouts().implicitlyWait(30, TimeUnit.SECONDS);
// Suppose a rotation of button takes 30 sec
driver.findElement(By.xpath("/html/body/div[2]")).click();
// action performs on the element
In ruby you have to use this type of syntax
#driver.manage.timeouts.implicit_wait = 30
I've implemented iScroll into a web page, intended for a smartphone. I haven't tried this yet in an emulator so I don't know if this is just a PC problem.
The scroller contains a UL. Each LI is marked with an onclick event handler:
$("li.myitem").click(showItemDetails);
...
function showItemDetails() ...
When I implemented this prior to using iScroll, if I click ONCE on a LI I get one call to my click handler (which opens another view window). After using iScroll I have two bad behaviors.
When scrolling around, sometimes iScroll thinks that I want to click on something. That is, iScroll is working something like an "onmouseup" event.
When clicking on an event, whether intentionally or not, iScroll is generating 10, 20 and even 30 events (or event threads) for that one place that a single event is intentioned for. I traced it, and all of the events are coming from the same LI item. This occurs just as badly if I change the click handler to a double-click handler (dblclick()).
In the immediate, I'm reduced to putting in a gatekeeper, a flag saying "I'm already busy with an event, go away". I could also change the interface to have the user click (select) an LI and then click on a separate button to see the details.
But I'm concerned about what iScroll is doing.
Any ideas? Need to see code? I can't put on the whole app (a thousand lines long, after comments), but I can show decent snips. But I'm hoping that this is an "oh, yeah" moment and someone tells me a known story.
I have a sliding carousel of items, each of which includes its own like button. I want the like buttons to have comments; that is, when the user clicks Like, he should be presented with a prompt to leave a comment (http://developers.facebook.com/blog/post/397/). I'm starting to doubt that these goals are compatible and would like to hear if anyone has already achieved it.
The comments on the Like buttons are wider than the items in the carousel, and correctly overflow onto other carousel items. However, some of these items are outside the clipping box, since the carousel items are necessarily inside a div with overflow: hidden (otherwise we wouldn't achieve the effect of the items scrolling into existence upon paging). Because of this, if I click Like on the rightmost item currently visible, the comments prompt that appears will be partially outside the clipping box and thus partially visible.
It appears to me the only possible hope of allowing the comments prompt to overflow the carousel container is to place the prompt outside the container in the dom. This way, assuming we can visually position the prompt next to its Like button where it belongs, it's no longer constrained by the container. This seems within possible, since at the time of this writing the comment prompt is implemented as a separate iframe from the button itself; i.e., this XFBML:
<fb:like width="450"></fb:like>
yields (approximately) this HTML:
<iframe src="facebook.com/like_button.php"></iframe>
<iframe src="facebook.com/comments_widget.php"></iframe>
But if I try to move the comments iframe in the dom, it instantly and permanently becomes empty. Even if I could find a way to detach certain events and prevent this, it shows that an intricate solution is called for, and one which Facebook can break at any time in the future with changes to their implementation. Thus, I can't move the comments in the dom, and thus, the prompt is always in danger of being clipped. Facebook says this on the subject:
If the Like button is placed near the edge of an HTML element with the overflow property set to hidden, the flyout may be clipped or completely hidden when the button is clicked. This can be remedied by setting setting the overflow property to a value other than hidden, such as visible, scroll, or auto.
Clearly in the case of a carousel it's not possible to remove overflow: hidden. Has anyone found a way around this, or should I give up and spend my time elsewhere?
Thanks