I'd like to find out the position of a clicked DOMElement in a WebView. In my delegate -[webView:decidePolicyForNavigationAction:request:frame:
decisionListener:] gets called. I can extract the clicked DOM element from the dictionary passed as actionInformation parameter. But I cannot figure out how to retrieve its position.
I tried get the click location through webview.window.currentEvent, but that returned some an WebKit event with a bogus location.
Any ideas how to solve this without dropping down into JavaScript?
The easiest way that should work without actual JavaScript is to use the Objective-C properties of DOMElement, which mirror the underlying JS properties. Unfortunately, there does not seem to be good documentation, but you can read the headers, e. g. WebKit/Headers/DOMElement.h etc.
Here, your best bet would be offsetLeft/Top/Width/Height. You need to add these to the scrollLeft/Top values of the document element. Also, for some elements, especially text or spans across multiple lines, calling the JS function getBoundingClientRect() would return better results. But you can do that from Objective-C as well, using the WebScriptObject API. If you need assistance with that, I can help.
Related
I have had this question a while, but I had never done anything about it. When mapping some elements for UI tests I sometimes come across elements that return two identical results.
We have got around this in the past by using findelements and then using an index [1].
But I still don't understand why it returns two elements when I can only see one in the code that should be located.
An example would be the following. You can see this username field box below.
And if I use some XPath expression like,
//input[#name='username']
I'm expecting only to get one element in return, but using the tool Chropath I can see that I get two elements in return.
These elements look identical, one is not hidden, etc.
I have never understood why this is happening, because if I use a findelement, I get an element, not interactable error, as I guess the driver can’t decide which one to use? Or they are in the way of one another.
So the workaround I have always used is:
return self.browser.find_elements(by=By.XPATH, value="//input[#name='username']")[1]
when I realisticly should be able to use:
return self.browser.find_element(by=By.XPATH, value="//input[#name='username']")
Why is this?
Some excellent response and it has made me understand what’s going on now. Moving forward, I will use the following:
for e in self.browser.find_elements(by=By.XPATH, value="//input[#name='username']"):
if e.is_displayed():
return e
This seems to work for me.
I see this often when a website has both the "desktop" version and a mobile or smaller screen version. At full (or near full) screen, the desktop elements are visible while the small screen elements are hidden. Once you resize the browser small enough, the desktop elements are hidden and the small screen elements become visible.
To get around this in a generic way, filter the returned two elements based on visibility, e.g.
return [e in self.browser.find_elements(by=By.XPATH, value="//input[#name='username']") if e.is_displayed()]
That should always return the visible element of the two.
The answer is within the snapshot:
The following xpath
//input[#name='username']
Identifies 2 different elements within the HTML DOM. Among the two matching elements, the first matching element is for mobile displays which remains hidden while you access the DOM Tree in Desktop mode. In the given snapshot of the Chropath the classname as modal-content-mobile is the best hint.
Solution
In these cases there are different approaches to identify the desired element. While some users tends to use an index and some users tends to probe the displayedness, from a personal perspective I find it quite easier and handy to traverse up the DOM to find the difference in attribute values in any of their ancestors and then finally follow down till the desired element.
It is possible you can have more than one same element on the page with same name attribute. One must be hidden.
If you want to access the first one use following xpath.
return self.browser.find_element(by=By.XPATH, value="(//input[#name='username'])[1]")
If you want to access last one use following
return self.browser.find_element(by=By.XPATH, value="(//input[#name='username'])[last()]")
It's quite often occurs that multiple elements will match the same locator.
For example, several code blocks may be implemented for login: one for a computer browser, another for a mobile browser, etc. The proper elements will be presented according to what you use to browse that page.
Selenium find_element always returns the first element found matching the passed locator on the page.
So, in case the first matching element is hidden return self.browser.find_element(by=By.XPATH, value="//input[#name='username']") will always retunt that hidden element.
You will need to make your locator more precise to match the desired web element.
A locator like "(//input[#name='username'])[2]" may be good, but it's better to use a unique parent element here, something like "//div[#class='pc_modal']//input[#name='username']", so your code would be something like this:
return self.browser.find_element(By.XPATH, "//div[#class='pc_modal']//input[#name='username']")
Well, in the strictest sense of way, no two elements have the same XPath expression. If you look at the absolute path, you will find the difference. The key is to find a path which is unique. In many case, you will find a web page where you find many textboxes/labels/dropdowns that have the same ids but are only differentiated by their absolute path.
Most of the times, such things depend on the framework used to develop the webpage and also developer's preference. An application developed in React will have a different DOM structure than one developed using Angular, for instance.
Yes, you are correct that it becomes difficult to find out which is the element of interest in such situations. In such cases, do not only depend on the particular element but add either a parent/sibling or ancestor to access the element. Although it might take some time and will jot be straightforward but it will be possible to find a unique XPath most of the times.
There are some test automation tools, like Ranorex, that have an object browser (objext spy as it is called) that can be used to pin on any web element and access its properties like hidden, visible. enabled, etc. But such tools are not free :(
I have 2 questions,
How can I set the value of the global search box and trigger the filter programmatically, using java script (basically I want to implement a persistent filter, based on the last user input, as the user navigates in and out of the page), check image below
Considering the Veu devtool component, I can find the vue-good-table Component and its Search subcomponent. And I can see that there is a value propuerty on this subcomponent that has the same value I had typed in the search box.
So my question is if with this information can I have a way to solve my first question, does the information in the Vue devtool can help me figure out the references to that object and value and then set it?
This could be a very useful tool in case I have a similar problem in the future with another component.
Have very little experience with Veu and general searches on how to access data or elements in components has been confusing, I just understand the properties and events to pass data, but in this case this is an imported component, so I can not hack it.
Thanks #tao, I read the docs before but skipped noticing this property
externalQuery
This is the one that solves the problem, you can link a variable to the search item and I then use your own text input box to implement the solution.
I have strange (at least to me) problem with multiple checkboxes with v-model. When using multiple checkboxes that are v-model'ed to one property then normal array is produced which is done with code below:
.form-check
input.form-check-input(type=“checkbox” name=“checkbox” v-model=“methodology” value=“issue tracking tool”)
label.form-check-label issue tracking tool
However, when I try to move it to Single File Component I had to copy some magical tricks from Vue.js forum to make it work. I still suspect that there must be easier way to achieve it. I can’t imagine that it wasn’t solved with simple solutions since it’s quite a common pattern (checkbox in a component - nothing exotic, right?). Any help appreciated!
Here is the working jsfiddle - please have in mind that there is no errors. I just want to know if that really has to be that complicated.
The answer is, no. You may be able to do this magic differently, but it needs to be done.
Vue has to do magic behind the scenes for checkbox because unlike all the other inputs, which have a single item that gets updated, the checkbox has to manage whether the a value is in an array. This means that the listeners and values have to be patched between the wrapper and input.
I would like to know what these options people are using more.
1) Using v-on on normal (div, span, etc) element
<div v-on:click="myFunction" class="cursor-pointer">Click me<div>
Here, it requires to have the a class to set up the pointer cursor to indicate that is can be clicked, and also, to increase the UX.
1) Using v-on on link element
Click me
Here, doesn't need to have any classe to set up the pointer cursor. However, it requires the prevent mode to stop the link action.
So, What is the best practice, advantages and drawbacks of these two approaches?
Ultimately, it doesn't really matter. Generally speaking though, you should be writing your HTML dom in Vue.js the same way you would write it without Vue.js. If something should be a link because it's leading to another view in your application, then <a> makes sense. If you wouldn't normally use an anchor link if it was just a static HTML page, then you're probably better to be writing it with a div, span, or whatever your developer instincts decide in that case.
Always try to write your code as if someone else is going to be looking at it, in which case they are going to have some expectation of what an <a> is supposed to be doing.
I'm trying to run the line of code below in my script, but I get an error saying that more than one object with these properties was found on the page.
Browser("browser").Page("page").WebElement("css:=.normalDayOfMonth").Click
So, I tried adding an index, as shown below:
Browser("browser").Page("page").WebElement("css:=.normalDayOfMonth", "index:=0").Click
But now it's not detecting any object at all. Could anyone help me out with this? Thanks!
Edit: For anyone else who comes across this, it turned out I was using QTP10 and as Motti pointed out below, CSS and Xpath support was only added in QTP11.
The support for using CSS and XPath to identify test objects was added in QTP11, in your comments you say that you're using QTP10 which would explain why you're facing problems...
What's probably happening is that QTP is ignoring css as an unrecognizd property so your description matches all elements and then when you add index:=0 it brings one of the invisible elements (e.g HEAD or HTML) which can't be clicked.
If all you're trying to do is match the className you can use QTP's class identification property ("class:=normalDayOfMonth").
BTW the Highlight function is an undocumented function similar to the object repository's highlight functionality and can be very useful in troubleshooting tests.