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'.
Related
I have a pop up window containing a script in its head. And this script should be triggered by click on the window button. But after click on this button the script does not run. Could you suggest the reason?
Steps to reproduce:
Click on a button in the main window.
Child window containing a simple form is open.
Move to the child window, fill in the form fields and click on submit button.
Expected result: The click triggers a script located in the child window head. The script process the form and submit it.
Actual result: an error arises: "submitMyForm is not defined" (reference: submitMyForm() is a method containing in the script mentioned above).
So the problem is that the child window form fields can be populated and form button can be clicked but the script bounded to the button by means of the link <a href="javascript:submitMyForm();"> does not work as the function submitMyForm() is not found. Obviously the reason of the test failure is stubbing the child window which is performed to prevent having 2 windows at the same time. After this the child window is opening in the same browser tab as Cypress is not able to work with 2 windows open in the same time. But in this case the script stops working neither from the test nor by performing the click manually.
Here is a code snippet from the Cypress test:
const pop_url = `/dir1/dir2/file.php?id=${sectionId}`; // Here is a new window URL
cy.window().then( win => {
const stub = cy.stub(win, 'open').as('windowopen');
newSurveySectionListObj.AddNewBtnClick(); // Triggers form opening in the new window
cy.get('#windowopen').should('be.called.with', pop_url);
cy.window().then( $win => {
$win.location.href = pop_url
newSurveySectionListObj.typeDropdownSelect('Matrix'); // works fine
newSurveySectionListObj.modalDescriptionFldType('Cypress test string'); // works fine
newSurveySectionListObj.responseTypeDropdownSelect('Checkbox'); // works fine
cy.get('a[href="javascript:submitMyForm();"]').click(); // Does not work despite the button is clicked. An error "submitMyForm is // not defined" arises
});
});
You are going beyond what Cypress is capable of/designed for.
I would question why you are using a separate window in your app? You will run afoul of pop-up blockers that will prevent the new window being opened anyway. A percentage of users won't be able to work it out.
There are 2 approaches to this:
Use a modal dialog to achieve this (not great on mobile)
Use another route/page to display your form, return to the prev page when done
These have the advantage that they won't break with pop-up blockers, and your Cypress tests will work, as they are still in the same window.
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
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 referred this for creating error message tool tips, to be displayed continuously unless the error is resolved by the user. :: http://aralbalkan.com/1125 .....................
But, this is being applied to a pop-up window visualized as a pop-up form.
When the user clicks 'CANCEL' button, I want the error message tooltips if present to be cleared off from the screen. The message tool tips remains on the screen even if the CANCEL button is clicked.
The tooltips created are not linked to the dialog pop-up directly - i.e. they're not created as child widgets of the pop-up.
To work around this you hook into the cancel button with an on-click hander, and have the handler loop through all elements in the errorMessageToolTips dictionary, hiding each one.
Depending on your code structure, to avoid problems later on you may want to make the errorMessageToolTips dictionary specific to the pop-up and not a global array.