fix: Update "find elements using"-strings #334
Conversation
Appium-clients have broadly agreed on using "-ios "-prefixes on strings used for iOS-exclusive element lookup strategies but the server can't provide those due to a mismatch
hanneshauer
changed the title
|
Why don't you modify find_element_by_ios_predicate ?
I personally think that such modification makes the code of |
There was a problem hiding this comment.
Appium-clients can't use the iOS Class Chain and iOS Predicate String queries because the strings WDA expects don't match the strings the clients send.
Sorry, what do you mean? Do you mean when your client sends requests to WDA directly case?
This module is designed to get requests by appium-xcuitest-driver. Appium clients communicate with Appium server (not directly to appium/WDA)
https://github.com/appium/appium-xcuitest-driver/blob/08ac6564964f5e7c7fcb7d32beb6ce22eee57d75/lib/commands/find.js#L26 transfers the -ios class chain to class chain for WDA. For WDA, all contexts are for iOS, so such prefix does not so much make sense for WDA.
I'd also recommend you to modify client side.
You can call find_element('class chain', 'your target') directly if you wanted to send a custom find element.
https://github.com/appium/python-client/blob/8205776240b4c92e021064751e5b113d0c915d50/appium/webdriver/webelement.py#L80
You are, of course, correct. My mistake was communicating with WDA directly instead of using appium-xcuitest-driver as a mediator which handles the string conversion and thus avoids the problems I've described. Sorry for the misunderstanding resulting from my setup, this obviously renders this PR moot. |
3 participants
Problem
Appium-clients can't use the iOS Class Chain and iOS Predicate String queries because the strings WDA expects don't match the strings the clients send.
Expected behaviour
When the client (I'm using the Python-client, but behaviour in other clients should be the same) requests to find elements using a class chain or predicate string WebElements matching the query should be returned if any are found.
Actual behaviour
Requesting to find elements results in an error because the WDA doesn't know how to handle the strings sent by the client.
Proposed fix
Change WDA to match the strings the clients are sending, i.e. prepend "-ios " to the "class chain" and "predicate string" usingTexts.
While it might seem backwards to change this in the server rather than adapt the clients, because multiple clients already use the same string and the "-ios "-prefix seems to have been established (in order to differentiate between lookup strategies that work exclusively on the iOS server) adapting the server seems like the more straight-forward fix.
Background
I've tried to find out when changes were introduced that made the server and client behaviour diverge but it turns out the respective strings have remained unchanged from when they were added around 3 years ago. I only tested the Python client because that's what I'm working with right now but searched through the other clients and all that have added support for class chain and predicate string lookups share the same strings, so the problem should exist for all of them. From what I can see none of those clients has been able to use these lookup strategies for years which seems odd but accurate from my research. I have found six clients linked from the official Appium documentation that all use the same "-ios..."-strings, so they seem to be an established pattern and fixing the server should make all of them work at the same time instead of having to fix all clients individually (it also seems like a reasonable idea to specially format strategies that work exclusively on iOS and are not supported by other Appium/Selenium servers).
Relevant GitHub code, issues and PRs: