[HOLD 15083][$1000] Invite members: Pressing Enter key focusing on search field adds the first highlighted user

[kavimuru]

If you haven’t already, check out our contributing guidelines for onboarding and email [email protected] to request to join our Slack channel!

---

Action Performed:

1. Open the app in mac safari, mac chrome, windows chrome
2. Open Workspaces
3. Open any workspace
4. Open manage members
5. Click on invite
6. Focus on search box and click enter

Expected Result:

App should select first user and enable invite button

Actual Result:

App directly adds first user to workspace in just single enter click i.e. in place of just selecting the first user, it triggers both selecting of first user and click on invite in just single enter click

Workaround:

unknown

Platforms:

Which of our officially supported platforms is this issue occurring on?

• Android / native
• Android / Chrome
• iOS / native
• iOS / Safari
• MacOS / Chrome / Safari
• MacOS / Desktop

Version Number: 1.2.85-1
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
Notes/Photos/Videos:

Recording.1714.mp4

single.enter.add.member.issue.mp4

Expensify/Expensify Issue URL:
Issue reported by: @eh2077
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1678871333569039

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~01c69f649944d8ab8a
• Upwork Job ID: 1636840800502415360
• Last Price Increase: 2023-03-17

[MelvinBot]

Triggered auto assignment to @strepanier03 (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details.

[MelvinBot]

Bug0 Triage Checklist (Main S/O)

• This "bug" occurs on a supported platform (ensure Platforms in OP are ✅)
• This bug is not a duplicate report (check E/App issues and #expensify-bugs)
  • If it is, comment with a link to the original report, close the issue and add any novel details to the original issue instead
• This bug is reproducible using the reproduction steps in the OP. S/O
  • If the reproduction steps are clear and you're unable to reproduce the bug, check with the reporter and QA first, then close the issue.
  • If the reproduction steps aren't clear and you determine the correct steps, please update the OP.
• This issue is filled out as thoroughly and clearly as possible
  • Pay special attention to the title, results, platforms where the bug occurs, and if the bug happens on staging/production.
• I have reviewed and subscribed to the linked Slack conversation to ensure Slack/Github stay in sync

[strepanier03]

I was able to recreate this behavior perfectly following the steps. I agree that we shouldn't have this behavior.

[MelvinBot]

Job added to Upwork: https://www.upwork.com/jobs/~01c69f649944d8ab8a

[MelvinBot]

Current assignee @strepanier03 is eligible for the External assigner, not assigning anyone new.

[MelvinBot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @Santhosh-Sellavel (External)

[MelvinBot]

Triggered auto assignment to @amyevans (External), see https://stackoverflow.com/c/expensify/questions/7972 for more details.

[bernhardoj]

Proposal

Please re-state the problem that we are trying to solve in this issue.

Pressing enter while focusing on the search input invite the user instead of selecting it.

What is the root cause of that problem?

The workspace invite page uses FormSubmit which will listen to enter key. If enter key is pressed inside input, it will call the onSubmit callback.

App/src/components/FormSubmit/index.js

Lines 28 to 31 in 772a947

	if (tagName === 'INPUT' || tagName === 'SELECT') {
	this.props.onSubmit();
	return;
	}

What changes do you think we should make in order to solve the problem?

I don't think we want to submit it when we press enter for invite member page, so we can just remove the FormSubmit from invite page.

[tienifr]

Proposal

Please re-state the problem that we are trying to solve in this issue.

App directly adds first user to workspace in just single enter click.

What is the root cause of that problem?

We're using FormSubmit in the invite member page here

App/src/pages/workspace/WorkspaceInvitePage.js

Line 289 in ac9019d

<FormSubmit style={[styles.flex1]} onSubmit={this.inviteUser}>

, which will submit the form if clicking enter when inside an input.

What changes do you think we should make in order to solve the problem?

Since the input enter event is already handled by the OptionsSelector we should not wrap the OptionsSelector inside the FormSubmit. We can move FormSubmit to wrap the personalMessagePrompt TextInput instead so that the form is only submitted if the personalMessagePrompt TextInput is focused.

This can be done by moving FormSubmit from here

App/src/pages/workspace/WorkspaceInvitePage.js

Line 289 in ac9019d

<FormSubmit style={[styles.flex1]} onSubmit={this.inviteUser}>

, to outside this element

App/src/pages/workspace/WorkspaceInvitePage.js

Line 336 in a00e18d

<View style={[styles.flexShrink0]}>

.

What alternative solutions did you explore? (Optional)

In the TextInput of the OptionsSelector, we can assign a unique identifier (an attribute or a nativeID) if the optionsSelector has canSelectMultipleOptions=true, then in the FormSubmit, we can check if the input has that unique identifier, if yes then we'll not automatically submit the form upon pressing Enter inside that input.

[Santhosh-Sellavel]

This should be put on hold as there is a flow change in #10906 and this could be fixed there.

cc: @JmillsExpensify @amyevans

[Santhosh-Sellavel]

Should be on hold for #15083

[amyevans]

Makes sense 👍

PR for that issue, for easier reference: #15672

[strepanier03]

Thank you @Santhosh-Sellavel 🙌

[amyevans]

Currently on hold

[strepanier03]

Thank you Amy 🙌

[amyevans]

The PR we're holding on is still under review.

[amyevans]

Ditto ^

[amyevans]

Looks like #15672 was recently merged, @Santhosh-Sellavel mind giving a quick evaluation of our next steps here?

[Santhosh-Sellavel]

We should still keep this on hold. I found another issue while testing that reported here

[eh2077]

There's an another new reported issue #18598 related to this one.

[strepanier03]

I see #18598 is closed as a non-bug and #15672 is closed.

Are we still in a holding pattern for another GH?

[strepanier03]

@amyevans - I'm sorry but can you take a look at this and let me know if we're still holding for something or if I should take this off hold or not?

[Santhosh-Sellavel]

I believe we are good to close this is the expected behaviour.

[amyevans]

👍 Closing to stay consistent with the expected behavior agreed upon in #18598

[eh2077]

Good to see this issue resolved! Wanted to ask if I am eligible for report bonus for this issue?

cc @amyevans @strepanier03

[Santhosh-Sellavel]

I think not because the refactoring was started before this one was reported.