I have a scraping script written in Ruby which uses Selenium, Watir and ChromeDriver, all is working just fine with a Chrome browser window, but trying to run in headless mode just hits;
Selenium::WebDriver::Error::UnknownError: unknown error: Element <input id="desired_element" type="checkbox" name="desired_element" checked="checked"> is not clickable at point (660, 594). Other element would receive the click: <html lang="en">...</html>
I'm using Watir 6.8 and latest Chromedriver 2.33.
Any ideas whats n=behind the different behavior of the page when in headless vs non headless, and how I can deal with this?
The error message is telling you what the problem is when it says "Other element would receive the click:"
This means some other element on the screen is covering the checkbox you are trying to interact with. Likely this is caused by whatever the default browser size in headless mode being different than the default size of your browser when it is run non-headless, resulting in a different arrangement of elements
We can verify if this is the case by asking the size of the window in both headless and normal modes and seeing if the resulting values are the same.
size = browser.window.size
puts "The browser window is #{size.width} wide by #{size.height} high"
There are a few potential ways to solve this:
Specify or alter the browser 'window' size. for example
browser.window.resize_to 1024, 768
I prefer this, and normally have a command such as that to set the
browser size right after it is initialized. Set either to the
minimum supported size for your site, or the minimum recommended
size
Use another means to 'click' on the checkbox, such as sending a space at it
#browser.checkbox(name: "desired_element").send_keys " "
I do not prefer this as it doesn't really solve the source of the problem and you may experience other similar issues interacting with other elements on the site as your script progresses.
The reason for this kind of error is that web page doesn't load well enough to locate the element. As you have mentioned that the tests previously passed when you had headless true such issues might be because of .click() , please try replacing .click with .send_keys
.send_keys(selenium.webdriver.common.keys.Keys.SPACE)
When you use .send_keys() you might hit one more issue if it is failing to find elements, for solving this you will have to find the elements
elements = driver.find_element_by_tag_name("html")
elements.send_keys(Keys.SPACE)
Hope this helps you.
Related
This question already has an answer here:
Karate UI button click support
(1 answer)
Closed 2 years ago.
I am quite new to Karate UI automation and I have a front end UI that has a SVG element which when clicked brings a drop down.
When I am writing the UI test for it, I get javascript evaluation error and hence seek some advice/help.
Here are the screenshots of the UI element and its CSS locator clearly seen on the screen
This is how the CSS locator shows up for the SVG element
This uniquely identifies the SVG element(the plus button)
svg[class='svg-inline--fa fa-plus-square fa-w-14 ']
This is the part of code that I have written to click it
And click("svg[class='svg-inline--fa fa-plus-square fa-w-14 ']")
And here is the error I get:
javascript evaluation failed: click("svg[class='svg-inline--fa fa-plus-square fa-w-14 ']"), js eval failed twice:document.querySelector("svg[class='svg-inline--fa fa-plus-square fa-w-14 ']").click(), error: {"type":"object","subtype":"error","className":"TypeError","description":"TypeError: Cannot read property 'click' of null\n at <anonymous>:1:78","objectId":"{\"injectedScriptId\":2,\"id\":3}"}
I tried various things that can uniquely identify the SVG element like using the compelete Xpath and also using the parent class name(though it was already unique with just the class name) but it still did not work. I tried wildcard locators as well but since there is no text/name of the element, it did not work. When the tags are say input or button etc the same way of css locator works but SVG ones did not for me.
tagname[unique_id of the element like key=value pair]
I am wondering if we need to use a different way to identify SVG elements using Karate UI? The same path when used in Selenium worked.
Since this is a UI that requires VPN connection and secure acccess, it may not be possible to provide a minimum code to try and replicate it. But am happy to provide more details if needed.
I have many such SVG elements on my UI and any help in this would be greatly appreciated.
Use selector hub as an extension to chrome, firefox, edge and opera. Ive only used with chrome and it worked fine and allowed me to quickly and easily find svg relative / absolute xpath. This worked no problems in a find and click capacity on numerous svg elements (via karate script)
2 suggestions.
Try to get some nearby element and work backwards: https://stackoverflow.com/a/63988977/143475
Figure out the location of the SVG and fire a mouse-click: https://stackoverflow.com/a/63828083/143475
Unable to give you specifics without a way to replicate, but - it should be possible to find a "pattern" so you can write a custom function as described in the docs. So that can be your goal, something like this:
* svgClick('svg-inline--fa')
page speed score - ?
I insert the website and after the score appears just with a "?"
Your site is slow to reach. See screenshot attached.
Running your site from California, it takes over 3.2 seconds for FCP - first contentful paint.
This is not good. This is why page speed is unable to take screen shots as it is taking too long. Hence it times out and displays "?" if any of its tests are failing due to timeout.
You want to speed up FCP. Load only important elements on your viewport. Lazy load images and use defer, async for scripts.
You can gain better insights with Lighthouse. Use Chrome browser, incognito mode, load up your site and use incognito mode. It tells you things you need to fix.
Good luck
Checked under the Speed Index section, there is an error which looks like below.
Speed Index
Error!
Chrome didn't collect any screenshots during the page load. Please make sure there is content visible on the page, and then try re-running Lighthouse. (SPEEDINDEX_OF_ZERO)
Fix that and try again it should show the number.
Hope this helps.
I am learning Python and attempting to build a program that will scrape specific data from a website, store it and then manipulate it.
Currently I run my application, it opens a new chrome browser window and loads the page correctly. The problem is it should begin to start scrolling down and loading the remaining elements on the page.
I know the code works because if I manually click somewhere on the page that doesn't normally illicit a response (white space/empty areas) the browser somehow comes into "focus" and begins to iterate through the loop that scrolls down the page (by sending keys) prints the data I am after. I also noticed if I click another similar "dead space" area that contains the header, it doesn't have the same effect. I am unsure if this is something specific to Chrome, iFrames or something of that nature but I am completely stumped and would greatly appreciate any help.
Any thoughts on why I need to manually click on the new chrome window for it to work would be great.
Update: Still having the same issue, even tried with Safari and the same problem seems to exist.
Fixed this with:
element = driver.find_element_by_css_selector("div[id^='app-container']")
action = ActionChains(driver)
action.click(on_element = element)
action.perform()
I have a big SVG document here, containing a map of all the quests in a certain online game. Each quest node is inside a SVG <a> element, linking to a distinct named anchor in a big HTML document that loads in another tab, containing further details about that particular quest. This works exactly as desired in desktop Safari, and I'd expect it to work just as well in any browser that supports SVG at all since I'm using only the most basic form of linking, but it fails badly on Mobile Safari (iOS 6) - which is my single most important browser target, considering that the game in question is for the iPad. It only scrolls to the correct anchor on the initial load of the HTML page; clicking a different quest in the SVG tab will cause a switch to the HTML tab, and the hash (fragment ID) in the address bar changes, but the page doesn't auto-scroll.
This appears to be a known limitation in Mobile Safari - hash-only changes in the URL apparently used to force a page reload, and that got over-fixed such that nothing gets triggered at all now. The fixes I've found online all seem to be applicable only in cases where the URL change is being generated programatically, from within the same document, rather than static links from a different document.
Further details:
I've tried doing the named anchors in both the old <a name="..."> form, and the newer <h1 id="..."> form. No difference.
I've tried adding an onhashchange handler, to force the scrolling to take place, but the handler isn't being called at all (verified by putting an alert() in it).
I could presumably fix the problem by having each quest's details in a separate HTML file, but that would severely affect usability - with all the details in a single file, you can use your browser's Find feature to search through them all at once. (Also, deploying 1006 files to my web hosting after each update would be a bit of a pain...)
Anybody have an idea for a work-around?
I have been working on this site for some time and just launched it for a client.
People have actually had trouble beleiving I had done it on WordPress, though I don't see why...
Anyway, I suddenly see that the form fields of one of the forms on the site (Newsletter Registration) disappear while on IE, you get to see them for a second and puff, they're gone. I did check this previously on IE and it worked, I especially used CSS3 PIE to get the rounded effect for the fields on IE...
Link to website: http://www.doritsivan.com (hope this isn't considered promotion, not my intention)
site is based on WordPress and jQuery.
resolved the issue, thank you all. it was a bad case of relative vs. absolute positioning and the fields decided to go away (literaly)
A bunch of debugging with firebug-lite (btw was real to get it to work on my IE, kept on crashing or refusing to load altogether combined with IE popup and security issues) and I understoid that this was the issue, then some pixel fiddling and all was good. rechecked in Chrome, saw that result was exactly the same. job done