fix: include multiline TextView in iOS accessibility dump

[Ernest94]

Problem

Multiline React Native TextInput components render on iOS as a UITextView, which WDA reports as XCUIElementTypeTextView. The accessibility-dump filter in devices/wda/source.go only accepted TextField (single-line UITextField), so multiline inputs were dropped from the tree entirely — making them impossible to locate (getByLabel()) or fill.

Fixes #293

Fix

Add TextView to both the acceptedTypes list and the alwaysInclude set in filterSourceElements, mirroring how TextField is handled (so it's kept even when it has no label/name yet, e.g. an auto-focused empty field).

Tests

Added two tests in source_test.go:

• a labeled multiline TextView is included in the dump
• an unlabeled TextView is always included

go test ./devices/wda/ passes.

🤖 Generated with Claude Code

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 268af242-c006-40f5-8365-2e642a47ff01

📥 Commits

Reviewing files that changed from the base of the PR and between 2b0278e and d211a16.

📒 Files selected for processing (2)

• devices/wda/source.go
• devices/wda/source_test.go

---

Walkthrough

This change updates the WDA source element filtering logic in devices/wda/source.go to accept TextView elements and always include them regardless of identifier presence. Corresponding unit tests were added in devices/wda/source_test.go to verify TextView elements are correctly retained in filtered results for both multiline text inputs and inputs lacking a label or identifier.

Changes

Area	Change
devices/wda/source.go	Added TextView to acceptedTypes and alwaysInclude in filterSourceElements
devices/wda/source_test.go	Added two tests verifying TextView inclusion behavior

Related PRs: None identified.

Suggested labels: bug, tests

Suggested reviewers: None identified.

🐰 A rabbit hops through XML trees so tall,
Finds TextView hiding, no label at all,
"Include it still!" the filter now cheers,
Two tests confirm it, dispelling all fears,
Multiline or bare, it's welcome to call.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly matches the main change: including multiline TextView elements in the iOS accessibility dump.
Description check	✅ Passed	The description is directly related to the code changes and test coverage in this pull request.
Linked Issues check	✅ Passed	The changes satisfy #293 by adding TextView to the accepted and always-include sets and covering labeled and unlabeled cases with tests.
Out of Scope Changes check	✅ Passed	The PR stays scoped to the TextView filtering fix and its unit tests, with no obvious unrelated changes.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}