-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Quickly finding all child elements #669
Comments
I would suggest using XPath |
Hello Karel. Thanks for the quick reply! but I’m afraid I’m not following. How could getting the count of elements speed up performance?
…________________________________
From: Karel Frajtak <[email protected]>
Sent: Sunday, April 14, 2019 12:09:36 AM
To: Microsoft/WinAppDriver
Cc: bkilada; Author
Subject: Re: [Microsoft/WinAppDriver] Quickly finding all child elements (#669)
I would suggest using XPath count function to get the number of child elements. That may speed up your code.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub<#669 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AWl8D5i7tBUSUw9NsM8dKmYvFUirYWfaks5vgtQwgaJpZM4cudC2>.
|
Now your code counts the elements on "client side", you run the query to find the elements you are interested in, transfer them to "clent side" and count them. But if you run query like But I am not 100% sure if you can run query like that in Selenium. |
@kfrajtak the counting operations (for example, "else if (childElements.Count == 0)") are not what's consuming large amounts of time. It's pretty much instant, since I already have the array of child elements acquired using FindElementsByXPath. I'm afraid that won't help. Anyway, there's no reason I can see why searching for elements should take so long. There are only 6 child elements under the root element, and even though I am only searching for immediate children using "/*" it still takes ~20 seconds to find those 6 elements. I'd think it would be fairly instantaneous. I think it might be searching other programs control trees as well, because I initially received a 60 second HTTP time out request and had to close all other open applications before the test ran successfully. |
These are valid observations and analysis on the current Windows Application Driver release. There is a known performance bottleneck on querying element(s) using XPath locator due to the existing implementation. It is fairly understood where the performance issue comes from and it is something that will be improved in the future. I am marking this is enhancement to keep it tracked and prioritized. |
Thanks for the reply. Well I guess I'm out of luck with my current approach, then. Perhaps I'll re-work it to get all elements at the start, the problem is that the availability of elements can change based on previous clicks; that's why I preferred the dynamic approach. Anyway, looking forward to a fix! |
When can we expect the enhancement? I am seeing the same issue with our application. It will be really helpful if it is quicker Regards, |
We use the XPath "*/*" to get the children of an element, e.g. The expected XPath "*" returns the element again, looks like a bug to me... |
@joerg1985 Thanks confirming that it works to find children using
This works to expensively find itself
|
I think you should be able to use |
Thank you, this simple prefix helped me as well. I agree that this looks like a bug... I was calling WindowsElement.FindElementByXPath("child::*") and it made no sense to get back the same element. |
C# code
|
Hello,
I recently discovered the WinAppDriver and have been attempting to create a GUI stress test using Appium that randomly clicks all elements in my application. I've hit a lot of snags along the way which I've worked around but this latest one I can't seem to conquer.
I have successfully written code that recursively does the following:
-----2. Click first child of "e" and check if the child also has children.
----------3. If yes, continue recursively until no more children.
----------4. If no, return.
-----5. Click second child of of element "e".
etc.
The problem is that querying to see if an element has children is extremely slow. I manually construct my own xPath so that I know which element to search underneath (since there's no way to get the xPath from an element otherwise) but even with the narrowed scope, it takes super long to find all children. We're talking about 24 seconds.
My question is:
Is there a faster way to find all the children of an element? Or perhaps, any tips on achieving a GUI stress test another way? The app is a rather complex Windows Forms app that also has hosted WPF controls.
I've pasted the test code below for reference.
The text was updated successfully, but these errors were encountered: