fix(appium): prefer exact text matches over substring in page-source filters - #161
Open
nt-ben-leblond wants to merge 1 commit into
Open
fix(appium): prefer exact text matches over substring in page-source filters#161nt-ben-leblond wants to merge 1 commit into
nt-ben-leblond wants to merge 1 commit into
Conversation
…filters FilterBySelector matched literal text selectors with case-insensitive CONTAINS only. On the Appium path that makes a plain selector like text: "0" resolve to the first node whose text merely contains 0 (e.g. a trading ticket price field "7000.00") ahead of the element whose text is exactly "0" (the switch), corrupting the flow — the TT-ticket failure seen through Sauce/Appium, where the webview exposes price text that the uiautomator2/devicelab drivers never surface. Literal text now prefers exact matches: when any element matches exactly, only those are returned; otherwise the existing contains semantics apply. Regex selectors are untouched. Adds a regression test for the price-field vs switch case and updates the FilterBySelector contract tests.
Codecov Report❌ Patch coverage is
📢 Thoughts on this report? Let us know! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
On the Appium driver path,
FilterBySelector's literal-text matching used case-insensitive CONTAINS only. A plain selector liketext: "0"therefore resolved to the first node whose text merely contains0(e.g. a trading order ticket's price field"7000.00") ahead of the element whose text is exactly"0"(the leg switch).That broke real flows on Sauce/Appium: WebViews expose price-field text that the uiautomator2/devicelab drivers never surface, so the same flow passes on a local/dcd device and fails on Appium with the tap landing in the wrong field (and downstream state corruption).
Change
Literal text now prefers exact matches:
looksLikeRegexgate).Tests
text: "0"over elements["7000.00" (price field), "0" (switch), "Limit"]resolves to the switch, while a non-exact literal still matches by contains.TestFilterBySelector_Android/TestFilterBySelector_iOSupdated to the new exact-first contract.Impact
Text selectors that target full labels (the common case, e.g.
text: "Good till Cancel") are unaffected — exact matches simply take precedence. Only flows that relied on an exact node ALSO existing when a substring matched could see a different (more specific) selection.