You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[$500] Room - First workspace becomes highlighted by default when creating new room for 2nd time #34393
Version Number: 1.4.24-4 Reproducible in staging?: Y Reproducible in production?: Y If this was caught during regression testing, add the test name, ID and link from TestRail: Email or phone of affected tester (no customers): Logs:https://stackoverflow.com/c/expensify/questions/4856 Expensify/Expensify Issue URL: Issue reported by: Applause - Internal Team Slack conversation:
Action Performed:
Click on FAB > New Chat > room > workspace
Observe no workspace is highlighted
Select the first workspace
Click outside of the panel to close it
Re do step 1
Expected Result:
No workspace should be highlighted by default
Actual Result:
The first workspace becomes highlighted
Workaround:
Unknown
Platforms:
Which of our officially supported platforms is this issue occurring on?
changed the title [-]Room - First workspace becomes highlighted by default when creating new room for 2nd time[/-][+][$500] Room - First workspace becomes highlighted by default when creating new room for 2nd time[/+]on Jan 11, 2024
Please re-state the problem that we are trying to solve in this issue.
Room - First workspace becomes highlighted by default when creating new room for 2nd time
What is the root cause of that problem?
We don't highlight the first option in the SelectionList because if we don't pass initiallyFocusedOptionKey no option will be focused because the fallback for focusedIndexis set to -1. Due to the updateAndScrollToFocusedIndex, the first option is highlighted sometimes.
What changes do you think we should make in order to solve the problem?
In my opinion, we should set the fallback for focusedIndex to 0 because in almost every SelectionList components, the first option is always highlighted. I believe it is good for the user experience to indicate that it can also be changed through keyboard navigation.
We can pass initiallyFocusedOptionKey if we don't want to change the fallback for focusedIndex. We will use the first item key in the options form initiallyFocusedOptionKey.
We can introduce a new prop inside BaseSelectionList to highlight the first option only if the prop is true. We will set the fallback property based on that.
Activity
[-]Room - First workspace becomes highlighted by default when creating new room for 2nd time[/-][+][$500] Room - First workspace becomes highlighted by default when creating new room for 2nd time[/+]melvin-bot commentedon Jan 11, 2024
Job added to Upwork: https://www.upwork.com/jobs/~01bc4717bf898902a4
melvin-bot commentedon Jan 11, 2024
Triggered auto assignment to @sophiepintoraetz (
Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details.melvin-bot commentedon Jan 11, 2024
Triggered auto assignment to Contributor-plus team member for initial proposal review - @aimane-chnaif (
External)rushatgabhane commentedon Jan 11, 2024
Please re-state the problem that we are trying to solve in this issue.
In selection list, the focusedIndex is set as
0even tho it should be-1What is the root cause of that problem?
This happens because when
sectionschange after first render ofSelectionList,updateAndScrollToFocusedIndexis called.It sets the index focused index to
0.App/src/components/SelectionList/BaseSelectionList.js
Lines 375 to 377 in c080ccc
What changes do you think we should make in order to solve the problem?
Change the dependency array of the useEffect to update only when its length changes
[sections?.length]App/src/components/SelectionList/BaseSelectionList.js
Line 379 in c080ccc
Krishna2323 commentedon Jan 11, 2024
Proposal
Please re-state the problem that we are trying to solve in this issue.
Room - First workspace becomes highlighted by default when creating new room for 2nd time
What is the root cause of that problem?
We don't highlight the first option in the
SelectionListbecause if we don't passinitiallyFocusedOptionKeyno option will be focused because the fallback forfocusedIndexis set to-1. Due to theupdateAndScrollToFocusedIndex, the first option is highlighted sometimes.App/src/components/SelectionList/BaseSelectionList.js
Lines 375 to 377 in c080ccc
What changes do you think we should make in order to solve the problem?
In my opinion, we should set the fallback for
focusedIndexto 0 because in almost everySelectionListcomponents, the first option is always highlighted. I believe it is good for the user experience to indicate that it can also be changed through keyboard navigation.We can just update this line:
App/src/components/SelectionList/BaseSelectionList.js
Line 157 in e0f0e40
To:
Result:
focus_index_selectionList.mp4
Optional:
initiallyFocusedOptionKeyif we don't want to change the fallback forfocusedIndex. We will use the first item key in the options forminitiallyFocusedOptionKey.BaseSelectionListto highlight the first option only if the prop is true. We will set the fallback property based on that.DylanDylann commentedon Jan 12, 2024
I think we should hold for #29080
68 remaining items
lschurr commentedon Mar 19, 2024
@aimane-chnaif - Should this be open to proposals externally? Is the original bug still happening?
aimane-chnaif commentedon Mar 19, 2024
This step is failing. First workspace is always highlighted
aimane-chnaif commentedon Mar 19, 2024
Expected Result:
No workspace should be highlighted by default
Actual Result:
The first workspace becomes highlighted
Should this be inverted?
lschurr commentedon Mar 19, 2024
Discussing here - https://expensify.slack.com/archives/C01GTK53T8Q/p1710877793579389
aimane-chnaif commentedon Mar 20, 2024
I am going to be OOO soon. Please assign new C+.
dukenv0307 commentedon Mar 20, 2024
@lschurr I'm a new C+ so I'm low on issues, I can take over 👍
lschurr commentedon Mar 20, 2024
Based on the Slack thread, I think we're going to ask QA to test again. @lanitochka17 can you confirm this bug is still reproducible?
lschurr commentedon Mar 25, 2024
Asking for help from QA: https://expensify.slack.com/archives/C9YU7BX5M/p1711381040209419
kavimuru commentedon Mar 25, 2024
@ishpaul777 bug is not rproducible
bandicam.2024-03-25.18-47-35-654.mp4
lschurr commentedon Mar 25, 2024
Closing since we're unable to reproduce.