Repository navigation
fix(e2e): anchor sidebar keyboard navigation on focus - #7774
Conversation
|
Navigate logical layers of code changes, visualize relationships, and explore their blast radius. No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configuration
📒 Files selected for processing (1)
Included review availability: This review used your included allowance. Your plan provides up to 8 included reviews per hour; 7 remain after this review. 📜 Recent review details⏰ Context from checks skipped due to timeout. (2)
🔇 Additional comments (1)
WalkthroughThe keyboard navigation test now searches for the sidebar accessibility element by pressing Down up to 10 times. It waits after each press and verifies focus before opening the element. ChangesKeyboard navigation test
Priority: ⬇️ Low Estimated code review effort: 2 (Simple) | ~8 minutes Change: Other Suggested labels: Merge Risk: ⚪ Minimal · up to No actionable merge-blocking issue is established. The test checks for the intended focus before opening the sidebar item. Architecture SummaryArchitecture risk: 🔵 Low · up to The changed surface does not map to a changed system, dependency edge, entrypoint, or external dependency. Changed systems: None identified. Architecture concerns Review detailsBefore / after behavior
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
Warning Errors were encountered while retrieving linked issues. Errors (1)
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. Comment |
|
Android Build Available Rocket.Chat 4.78.0.109899 Internal App Sharing: https://play.google.com/apps/test/RQQ8k09hlnQ/ahAO29uNQsOlVMfordJSHh1UxqmTEf9h7P0zKcxpeCcN9b2VgnzpfPtfE4fkf5vLbNJxiLKJrzMvDrQDB_oCnodaPN |
|
iOS Build Available Rocket.Chat 4.78.0.109901 |
…ount The flow opened the drawer and pressed Left, Down, Down to reach Accessibility & Appearance. Left only moved focus because every room row kept its swipe action buttons mounted behind the row, and Down from one of those hidden buttons landed on the drawer's Profile item. Swipe actions now mount only while a row is swiped, so Left has nowhere to go and the two Downs stop on Edit status. Press Down until the Accessibility item holds focus, bounded and asserted like the login steps in the onboarding flow. The focused view is the keyboard-focus wrapper, which carries no testID, so the selector matches it by its sidebar-accessibility descendant.
9d051da to
febddef
Compare
Proposed changes
The Android Maestro flow "Keyboard Navigation Components" (shard 14) fails on every PR with
Assertion is false: "Theme" is visible.The flow reached Accessibility & Appearance in the drawer by pressing Left, Down, Down. Left only moved focus because every room row kept its swipe action buttons mounted, hidden behind the row; Down from one of those buttons landed on the drawer's Profile item. Since #7719 the actions mount only while a row is swiped, so Left goes nowhere and the two Downs stop on Edit status.
Keyboard focus reaching invisible buttons was a defect, so the app is right and the flow is changed: it presses Down until the Accessibility & Appearance item holds focus (at most 10 presses), asserts that focus, then presses Enter, the same pattern as #7703.
The focused view is the keyboard-focus wrapper around the list item, which has no testID, so the selector matches it through its
sidebar-accessibilitydescendant.Issue(s)
https://rocketchat.atlassian.net/browse/NATIVE-1721
How to test or reproduce
hw.keyboard=yes, as shard 14 does on CI..maestro/tests/keyboardNavigation/keyboard-navigation-components.yaml."Theme" is visiblefails. After: the flow passes.Screenshots
Types of changes
Checklist
Further comments
Summary by CodeRabbit