Can use keyboard arrow when chat switcher is open to get to the chat composer

[roryabraham]

Posted to Upwork: https://www.upwork.com/jobs/~017933fc9690ffbd93

Title:
mWEB- Chat.Exp- 1.0.1-333 - Chat - Able to type messages in the list of contacts after hit on arrow

Action Performed

1. Go to URL https://chat.expensify.com
2. Log in with any account
3. On Search box Add one of your contact
4. Hit on arrow down
5. Start typing something

Expected Result:
Unable to type messages in the list of contacts

Actual Result:
Able to type messages in the list of contacts

Tester login credentials - Password : Feya86Katya
Tester login credentials - Email/Phone : [email protected]

OS and browser used: Safari
Build: 1.0.1-333

Attachment
Video

[UpworkBartkoski]

In the current codebase, I can't reproduce this issue.

[arisferyanto]

Hi @roryabraham, I can reproduce the issue on latest master branch and have a solution ready. Please check my proposal on upwork. Thanks!

[laurenreidexpensify]

Hi @UpworkBartkoski are you still having issues reproducing?

[UpworkBartkoski]

Hi @UpworkBartkoski are you still having issues reproducing?

I was able to reproducing the issue and fixed it

[UpworkBartkoski]

I am working on this.

[arisferyanto]

I saw there was no one hired yet the last time I opened this issue. That's why I checked on it. Sorry @UpworkBartkoski @laurenreidexpensify!

Anyway, PR #1268 depends on isSidebarShown. Whenever the condition for isSidebarShown changes, we need to test again & probably make some more changes (e.g., here). There is a better way that doesn't depend on isSidebarShown.

[roryabraham]

Whenever the condition for isSidebarShown changes, we need to test again & probably make some more changes (e.g., here).

I don't think this is true - check out the react-native-onyx repo. Since ReportActionCompose is wrapped in withOnyx, and the isSidebarShown prop is bound to Onyx, whenever that data changes in the underlying store, the component will be re-rendered, and the updated prop will be provided in the render function.

[arisferyanto]

Hi @roryabraham, you can take a look at this alternative. If you think it's good, feel free to use it. It's not going to be of any use sitting in my local repo here anyway.
5037950...arisferyanto:1228

[marcaaron]

I am a bit confused by the premise of this issue. What are we fixing here exactly?

[marcaaron]

Able to type messages in the list of contacts

I am interpreting this as... we should be able to type the message, but the sidebar is in the way? That might be a more accessible way to handle this situation.

[roryabraham]

What happens is:

1. You open the chat switcher to search for chats
2. When the chat switcher text input is focused, you can use the down arrow on the iOS key, and it will move to the next text input in the DOM. In this case, that's the ReportActionCompose
3. When you switch to the ReportActionCompose, you're able to type the message, but the sidebar is in the way.

You're correct that an alternate (maybe better) solution to this would be to hide the sidebar when they hit the arrow down key. I hadn't thought of that.

[marcaaron]

Yeah I'd think we'd just cycle back and forth. e.g. if you focus on one or the other input then the sidebar should open/close?

[arisferyanto]

From user's perspective, I don't think they expect pressing the arrow button will close the sidebar and focus the cursor on the chat input box, especially because the chat input box is not visible when sidebar is open. It's okay for a single page where multiple input elements are visible to the user, but not in this case. Just my 2 cents.

[marcaaron]

the chat input box is not visible when sidebar is open

I can see that argument and wouldn't mind that approach. Perhaps we should not render the text input at all while the sidebar is open? The user only has the option to tab over because it's rendered behind the sidebar after all.

[parasharrajat]

We can use the tabIndex prop to manage the focus while the sidebar is open thus browser will not tab away.

[Jag96]

It doesn't look like any technical proposal was made here, but it sounds like the latest agreement is that the up/down arrows shown in the description of the issue should not be tappable when the side menu is open.

In the future, please be sure to submit a technical proposal before opening a PR to fix an issue. For the PRs currently open, please ensure they are updated to account for this.

[UpworkBartkoski]

@Jag96
So should I go back to the first solution I did?
3cf5b69

[Jag96]

@UpworkBartkoski I've commented on the PR