Wait required before Selenium-ChomeDriver/Chome can click element correctly (ChromeDriver v 77 & 78, Chome v 78) - selenium

As mentioned in the title, the following issue occurs since chrome was updated to v78. Before chrome v78 all tests worked just fine.
The behavior is highly nondeterministic, so please bear with me.
Meaning sometimes it just works out of a sudden, without any changes. Most of the clicks in the tests are working. Just some fail repeatedly (most of the time).
We are using selenium with the latest driver for chrome 78. The problem appeared first on driver version 77 with chrome 78 running.
Not the spec-flow tests nor the adapter-code has changed in any way, but after the Chrome update basically all tests failed.
Doing a Thread.Wait(1000) before EVERY CLICK seems to be the most reliable way to avoid the problem, and clicks the element as requested.
When im not waiting, the driver runs through the "Click", including the steps listed below, without actually clicking or throwing any error.
lookup of the element:
new WebDriverWait(this.webDriver, this.WaitTimeout).Until<IWebElement>(SeleniumExtras.WaitHelpers.ExpectedConditions.ElementIsVisible(by))
waiting for the element to be clickable:
wait.Until(SeleniumExtras.WaitHelpers.ExpectedConditions.ElementToBeClickable(by));
scrolling towards the element:
((IJavaScriptExecutor) this.webDriver).ExecuteScript("window.scrollTo(0, " + (object) (e.Location.Y - 250) + ")");
and performing a click and release action on the element:
action.Click(element).Perform()
i have also tried several other variants of mouse clicks including the one from the comment.
Since the process just works through all this, without actually throwing an error or warning of any kind, i have no way of checking if the click actually happened (other than checking the current URL, which would be a nightmare to maintain in the tests).
So the website is not updating and remains on the source page and the test will fail because the next test doesn't run on the expected page.
now the question:
Is there anything i can query for or wait for to see whether the driver or chrome can actually click that element (really) or to verify that it was actually clicked?
original issue report:
https://github.com/jsakamoto/nupkg-selenium-webdriver-chromedriver/issues/66

Related

Trying to automate a web page and pause in debugger error [duplicate]

Everytime I try to access this website and open google-chrome-devtools I am unable to inspect any of the elements through the Inspector as the UI is having an overlay along with a message Paused in debugger.
The upvoted and accepted answer of this discussion says to check the Source tab, check under the Event Listener Breakpoints panel if you've set any breakpoints under 'Mouse'. I have cross checked that none of the Sources -> EventListenerBreakpoint are set.
The upvoted and accepted answer of this discussion says to check if the little octagonal stop/pause sign (at lower left of Chrome "Sources") is colored (blue or purple). I am not sure why do I need to do that additionally for selected websites.
Snapshot:
The upvoted and accepted answer of this discussion speaks about the Manual Steps.
All the solutions seem to point towards the manual process. But this issue seems to me the root cause behind Selenium being unable to getPageSource().
Code trials:
System.setProperty("webdriver.chrome.driver", "C:\\Utility\\BrowserDrivers\\chromedriver.exe");
ChromeOptions options = new ChromeOptions();
options.addArguments("start-maximized");
options.addArguments("disable-infobars");
options.addArguments("--disable-extensions");
WebDriver driver = new ChromeDriver(options);
driver.get("http://rd.huangpuqu.sh.cn/website/html/shprd/shprd_tpxw/List/list_0.htm");
Output: Chrome opens but doesn't navigates to the url.
So my questions are:
In which case can Paused in debugger error occurs?
Is it an error from the frontend development?
How can I bypass this error during the Automated Tests through Selenium?
In which cases can the Paused in debugger error occur?
Anytime you are accessing this page with the dev tools open. The debugger; line will pause javascript execution, but browsers will ignore it if the dev tools are closed.
Is it an error from the frontend development?
In this case, no--they're deliberately trying to keep you out. The purpose of this function is to pause execution and then redirect your browser to a different page if it takes longer than 100ms to resume. I would speculate that this is designed to interfere with automated crawlers like selenium, because a regular user wouldn't be affected and a human developer can just hack around it.
How can I bypass this error during the Automated Tests through Selenium?
My first recommendation would be to try running Selenium headlessly, if that's an option. If not, use the hotkey to resume execution (F8). You can use whatever method you like for generating a keypress; with the java.awt package it will look something like this:
Robot robot = null;
try
{
robot = new Robot();
}
catch(Exception e)
{
//handle failure
}
robot.keyPress(KeyEvent.VK_F8);
Remember that you have to trigger this within 100ms, so use whatever logic you like to detect the block and respond quickly. If you just want something quick and dirty, I would just make it spam F8 keypresses every 50ms for a period of time until you're certain the page has loaded.
EDIT: On further investigation, this page is extremely messy and hostile to anyone with the dev tools open. There is not one but several functions that trigger debugger;and they get called repeatedly on a timer for as long as you're on the page. Running headlessly seems like the best choice, unless you want to continue spamming F8 for the entire session.

Debugger.setPauseOnExceptions for Selenium debugging not working [duplicate]

Everytime I try to access this website and open google-chrome-devtools I am unable to inspect any of the elements through the Inspector as the UI is having an overlay along with a message Paused in debugger.
The upvoted and accepted answer of this discussion says to check the Source tab, check under the Event Listener Breakpoints panel if you've set any breakpoints under 'Mouse'. I have cross checked that none of the Sources -> EventListenerBreakpoint are set.
The upvoted and accepted answer of this discussion says to check if the little octagonal stop/pause sign (at lower left of Chrome "Sources") is colored (blue or purple). I am not sure why do I need to do that additionally for selected websites.
Snapshot:
The upvoted and accepted answer of this discussion speaks about the Manual Steps.
All the solutions seem to point towards the manual process. But this issue seems to me the root cause behind Selenium being unable to getPageSource().
Code trials:
System.setProperty("webdriver.chrome.driver", "C:\\Utility\\BrowserDrivers\\chromedriver.exe");
ChromeOptions options = new ChromeOptions();
options.addArguments("start-maximized");
options.addArguments("disable-infobars");
options.addArguments("--disable-extensions");
WebDriver driver = new ChromeDriver(options);
driver.get("http://rd.huangpuqu.sh.cn/website/html/shprd/shprd_tpxw/List/list_0.htm");
Output: Chrome opens but doesn't navigates to the url.
So my questions are:
In which case can Paused in debugger error occurs?
Is it an error from the frontend development?
How can I bypass this error during the Automated Tests through Selenium?
In which cases can the Paused in debugger error occur?
Anytime you are accessing this page with the dev tools open. The debugger; line will pause javascript execution, but browsers will ignore it if the dev tools are closed.
Is it an error from the frontend development?
In this case, no--they're deliberately trying to keep you out. The purpose of this function is to pause execution and then redirect your browser to a different page if it takes longer than 100ms to resume. I would speculate that this is designed to interfere with automated crawlers like selenium, because a regular user wouldn't be affected and a human developer can just hack around it.
How can I bypass this error during the Automated Tests through Selenium?
My first recommendation would be to try running Selenium headlessly, if that's an option. If not, use the hotkey to resume execution (F8). You can use whatever method you like for generating a keypress; with the java.awt package it will look something like this:
Robot robot = null;
try
{
robot = new Robot();
}
catch(Exception e)
{
//handle failure
}
robot.keyPress(KeyEvent.VK_F8);
Remember that you have to trigger this within 100ms, so use whatever logic you like to detect the block and respond quickly. If you just want something quick and dirty, I would just make it spam F8 keypresses every 50ms for a period of time until you're certain the page has loaded.
EDIT: On further investigation, this page is extremely messy and hostile to anyone with the dev tools open. There is not one but several functions that trigger debugger;and they get called repeatedly on a timer for as long as you're on the page. Running headlessly seems like the best choice, unless you want to continue spamming F8 for the entire session.

When invoking js.exec in Geb/Spock, the exec method is flagged as 'null'

I am creating a suite of tests (using Geb/Spock) for a web site. In one of them, the element I want to access is on the top of the page, so, to make sure that is visible, I want to scroll to the top of the page.
The command I am using is:
browser.js.exec('window.scrollTo(0, 0);')
or variations of it like
js.exec('window.scrollTo(0, 0);')
or other alternative like:
js.exec('window.scrollBy(0, -250);')
None of them makes the page scroll up, and when executing I get the following error (it is the only error, no other feedback). The error message using the other options listed above is identical (other than the command itself):
Condition not satisfied:
browser.js.exec('window.scrollTo(0, 0);')
| | |
| | null
| geb.js.JavascriptInterface#4019094f
geb.Browser#3dcac33e
at UserCreatesCompany.Go to Home Page and click on the log to
GitHub button as user User1(UserCreatesCompany.groovy:170)
I can not interpret the message that 'exec' is null. What exactly it means?
To make things more interesting, at the end of this script I am running the following cleanup procedure
js.exec('window.scrollTo(0, document.body.scrollHeight);')
DeleteButton.click()
$("button",'data-automation-id':"button-modal-yes").click()
}
and that works well: the page scrolls down. So, does not seem a problem about some missing library.
Any suggestion of what I may be doing wrong?
The version of the different components I am using is:
groovyVersion = '2.5.4'
gebVersion = '2.3'
seleniumVersion = '3.141.59'
chromeDriverVersion = '2.45'
First of all, you should not need to ever manually scroll the page to make elements visible - Selenium WebDriver which is underpinning Geb will do that for you automatically as soon as you start interacting (clicking, setting value, etc) with content.
Secondly, the failure you are getting is a failed assertion coming from a statement in an automatically asserted (then: or expect:) Spock block. It feels to me that you don't understand a concept which is core to Spock and therefore you should read about it in the manual first. It should make the failure you're getting clearer.
Thanks for the answer. Clearly: I was not fully aware of the different constrains the different blocks impose on what is executable or not. The manual is pretty clear once you have stumbled!
I am intrigued by your first assertion pointing that Selenium WebDriver will move to the element as soon as I interact with it. That was my understanding but it was not working. I made sure the element in question had a unique identifier, but still, it was not able to found it if the element had to be found by scrolling up. On the other hand it worked smoothly when locating the element WebDriver scrolled the page down.
Thanks again for the explanation. I have learn something new today!

JavaScript Error: e is null popup during Selenium Test

I have test which is resulting in a Firefox pop-up which looks like this:
The exception is an InvalidOperationException and it goes on to say
JavaScript Error: "e is null" then making reference to a JavaScript file called commandprocessor.js
I am using the 2.44.0 version of WebDriver with Firefox version 33.
Out of completeness, I will also add that this pop-up is not throw on if a user manually follows the steps in that test.
Any ideas what is going on? Previous SO questions with similar error have yielded no answer.
Could be an issue with the driver itself. Have you looked at these issues logged with selenium webdriver?
Issue 7977: Upredictable javascript errors "e is null"
Issue 8095: fxdriver.error.toJSON fails to match qualified method names containing $
Based on the rev logs these fixes seemed to have been added after 2.44.0 release so they may not have made it yet to a release version.
In one of the callbacks, the code included
$('#confirmRegistration').attr('href', 'javascript:location.reload();');
Seems to be forcing a page reload, which the WebDriver did not like.

Element not being added when running test through webdriver

I am working on writing a story for a bdd framework which uses jbehave/selenium/webdriver and am having a problem where the test encounters an error while running the story but appears to be fine when running manually. I'm having a problem where javascript for the functionality I'm testing behaves slightly different when I'm running tests manually on firefox vs through selenium web driver on the same system/version of firefox and this difference is causing a js error.
I've debugged and basically the root of the problem appears to be that var request_XML_container = $('div_appendpoint_id'); returns something different when I'm running the test manually vs when I run through the bdd framework.
var request_XML_container = $('div_appendpoint_id');
request_XML_container.innerHTML = encoded_xml_from_request;
var pos = method_to_get_position('id_of_place_div_should_be_appended_to');
// JS exception is thrown saying that style is not defined **ONLY**
// when running through web driver. Running test manually on
// same system and same browser works fine.
request_XML_container.style.left = (pos[0] - 300) + 'px';
request_XML_container.style.top = (pos[1] + 25) + 'px';
request_XML_container.style.display = "block";
Why this would work fine when running manually that var request_XML_container = $('div_appendpoint_id'); would return an item with style defined, but when running through webdriver that the style attribute of the element would not be defined?
UPDATE: I had originally thought that this was updating an iframe, but I read the markup wrong and the iframe I saw is a sibling - not a parent - of the element where the response is being appended to. I'm trying to simply append the response to a div. To be honest, this only makes things more confusing as grabbing a div by id should be pretty straight forward and I'm now sure why webdriver would be producing a different return element in this situation.
UPDATE 2: Steps to reproduce and information about the system I'm on:
Use webdriver to navigate to this url: http://fiddle.jshell.net/C3VB5/11/show/
Have webdriver click the button. It should not work
Run your test again, but pause put a breakpoint at your code to click the driver
Click the button on the browser that webdriver opened. It should not work
Refresh the browser page on the browser that webdriver opened. Now, it should work.
System details:
OS : OS X 10.8.5 (12F37)
IDE : Eclipse Kepler: Build id: 20130614-0229
Browser (used manually and by webdriver) : Firefox 23.0.1
Selenium version: 2.35.0
UPDATE 3: I have provided this maven project on github to aid in reproducing: https://github.com/dkwestbr/WebdriverBug/tree/master/Webdriver
Synopsis/tl:dr; Basically, in certain situations it appears as though webdriver is overwriting the '$()' javascript method with a method that does not return an HTMLElement with innerHTML or style defined (among other things). This post details the issue and how to reproduce.
I have opened this ticket to track the issue: https://code.google.com/p/selenium/issues/detail?id=6287&thanks=6287&ts=1379519170
I have confirmed that this is a bug with the Thucydides framework (understandable since they still aren't at a 1.0 release).
Issue can be tracked here: https://java.net/jira/browse/THUCYDIDES-203