fix: improve keyboard navigation in search conversations [WPB-14665] [WPB-14778]#4837
fix: improve keyboard navigation in search conversations [WPB-14665] [WPB-14778]#4837Garzas wants to merge 5 commits into
Conversation
| canSendMessage: Boolean, | ||
| onSendButtonClicked: () -> Unit, | ||
| ) { | ||
| if (event.isShiftPressed) { |
There was a problem hiding this comment.
We should probably disable "send on enter" when input field is in "expanded" mode.
There was a problem hiding this comment.
Removed changes from MessageComposer, because it will need to be a separate refactor
522503c to
384f202
Compare
|
@Garzas looks like you are rolling back kalium to a previous commitish. This means that the PR's target branch (develop) is using a newer version of Kalium, and the changes in this PR will rollback Kalium to an older version.
Is this intentional? |
Codecov Report❌ Patch coverage is
❌ Your patch check has failed because the patch coverage (0.00%) is below the target coverage (80.00%). You can increase the patch coverage or adjust the target coverage. Additional details and impacted files@@ Coverage Diff @@
## develop #4837 +/- ##
===========================================
- Coverage 51.29% 51.28% -0.01%
===========================================
Files 611 612 +1
Lines 21201 21205 +4
Branches 3407 3409 +2
===========================================
Hits 10875 10875
- Misses 9310 9314 +4
Partials 1016 1016
Continue to review full report in Codecov by Sentry.
🚀 New features to boost your workflow:
|
|
| searchBarState.isSearchActive -> SearchConversationsEmptyContent(onNewConversationClicked = onNewConversationClicked) | ||
| searchBarState.isSearchActive -> SearchConversationsEmptyContent( | ||
| onNewConversationClicked = onNewConversationClicked, | ||
| newConversationFocusRequester = emptySearchResultFocusRequester |
There was a problem hiding this comment.
Do we need to explicitly pass it as a parameter to the SearchConversationsEmptyContent? Inside that composable it just adds it to the modifier so we could do that here directly:
SearchConversationsEmptyContent(
onNewConversationClicked = onNewConversationClicked,
modifier = emptySearchResultFocusRequester?.let { Modifier.focusRequester(it) } ?: Modifier,
)
| searchFocusRequester: FocusRequester? = null, | ||
| fabFocusRequester: FocusRequester? = null, |
There was a problem hiding this comment.
Would it be possible to have only single parameter and make HomeTopBar not having the logic of deciding itself which one should be used next? For instance if we use this top bar in another scenario where we have completely different elements on a screen then we will need to add more focusRequesters. 🤔
Instead, we could pass single nextFocusRequester and move the logic of deciding which one it should be to the parent, because now it feels like some part of the logic which decides which one to use next is here inside HomeTopBar and some is in the parent for instance when passing parameters:
fabFocusRequester = if (currentNavigationItem.fab != null) fabFocusRequester else null,



https://wearezeta.atlassian.net/browse/WPB-14665
PR Submission Checklist for internal contributors
The PR Title
SQPIT-764The PR Description
What's new in this PR?
Issues
Fixed issues:
xbutton in the search field was skipped by keyboard focus in some search states.SHIFT+TAB, but not forwards withTAB.Causes
The affected Compose search components relied mostly on default focus traversal. This was not enough for dynamic UI states such as inactive/active search, conditionally visible clear actions, empty search results, and FAB visibility.
Some focus behavior also needed to be attached directly to the actual text input or focusable control so keyboard traversal would not skip intermediate actions.
Solutions
focusPropertiesfor the Conversations home top bar, profile action, FAB/New button, search field, clear search button, and search back button.xbutton when text is present.onEscapeOrBackKeymodifier used by search UI to close keyboard-driven search state consistently.