[HOLD #20353] [$1000] Enter key isn’t creating new line for new members invitation message textinput

[kavimuru]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Action Performed:

1. Goto Settings -> Workspaces
2. Select any workspace
3. Goto Manage Members -> Invite
4. Select members and click next
5. Observe that Enter key isn’t considered and not creating new line for the textinput

Expected Result:

It should create new line within textinput

Actual Result:

It isn’t creating new line

Workaround:

Can the user still use Expensify without this being fixed? Have you informed them of the workaround?

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.3.10-0
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: Any additional supporting documentation

Screen.Recording.2023-05-03.at.10.04.08.PM.mov

Recording.478.mp4

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

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~016a25a3c41bc6b912
• Upwork Job ID: 1654599849268609024
• Last Price Increase: 2023-05-26

[MelvinBot]

Triggered auto assignment to @sakluger (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

[Pujan92]

Proposal

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

Shift+Enter is not creating the new line for the invite message multiline textinput

What is the root cause of that problem?

Before reaching to the invite message page we are selecting the members from the invite members page, in that we have OptionsSelector which is creating a subscribe event for ENTER on componentDidMount.
Behavior of this key has been manipulated here according to the select items from the OptionsList.

App/src/components/OptionsSelector/BaseOptionsSelector.js

Lines 57 to 95 in b996b4d

	componentDidMount() {
	const enterConfig = CONST.KEYBOARD_SHORTCUTS.ENTER;
	this.unsubscribeEnter = KeyboardShortcut.subscribe(
	enterConfig.shortcutKey,
	() => {
	const focusedOption = this.state.allOptions[this.state.focusedIndex];
	if (!focusedOption) {
	return;
	}
	this.selectRow(focusedOption);
	},
	enterConfig.descriptionKey,
	enterConfig.modifiers,
	true,
	() => !this.state.allOptions[this.state.focusedIndex],
	1,
	);
	const CTRLEnterConfig = CONST.KEYBOARD_SHORTCUTS.CTRL_ENTER;
	this.unsubscribeCTRLEnter = KeyboardShortcut.subscribe(
	CTRLEnterConfig.shortcutKey,
	() => {
	if (this.props.canSelectMultipleOptions) {
	this.props.onConfirmSelection();
	return;
	}
	const focusedOption = this.state.allOptions[this.state.focusedIndex];
	if (!focusedOption) {
	return;
	}
	this.selectRow(focusedOption);
	},
	CTRLEnterConfig.descriptionKey,
	CTRLEnterConfig.modifiers,
	true,
	);

App/src/pages/workspace/WorkspaceInvitePage.js

Line 300 in b996b4d

<OptionsSelector

This(OptionsSelector) component isn't unmounted as the parent component remains due to we are moving the navigation in forward dir. For this key subscribe method we are not providing excludedNodes and all these are the cause for the issue.

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

We need to provide the excludedNodes with item TextArea for these subscribe methods like the way we are providing for the Up/Down arrow keys within ArrowKeyFocusManager. With this change for textinput it won't consider OptionsSelector callback function.

App/src/components/ArrowKeyFocusManager.js

Line 55 in b996b4d

}, arrowUpConfig.descriptionKey, arrowUpConfig.modifiers, true, false, 1, true, [this.props.shouldExcludeTextAreaNodes && 'TEXTAREA']);

[MelvinBot]

Looks like something related to react-navigation may have been mentioned in this issue discussion.

As a reminder, please make sure that all proposals are not workarounds and that any and all attempt to fix the issue holistically have been made before proceeding with a solution. Proposals to change our DeprecatedCustomActions.js files should not be accepted.

Feel free to drop a note in #expensify-open-source with any questions.

[aldo-expensify]

This is also broken in the main composer in staging I think

[Pujan92]

@aldo-expensify this commit seems breaking it where closeShortcutEnterModalConfig is configured for ENTER key.

[sakluger]

Checking with Aldo to see ifthat PR did cause a regression.

[aldo-expensify]

@Pujan92 is correct about the root cause here: #18419 (comment)

I'm not sure about what PR introduced this bug yet. The code that added the ENTER shortcut that prevents the enter key from working correctly has been there for a while:

App/src/components/OptionsSelector/BaseOptionsSelector.js

Lines 59 to 74 in 983da48

	this.unsubscribeEnter = KeyboardShortcut.subscribe(
	enterConfig.shortcutKey,
	() => {
	const focusedOption = this.state.allOptions[this.state.focusedIndex];
	if (!focusedOption) {
	return;
	}
	this.selectRow(focusedOption);
	},
	enterConfig.descriptionKey,
	enterConfig.modifiers,
	true,
	() => !this.state.allOptions[this.state.focusedIndex],
	1,
	);

[aldo-expensify]

@Pujan92 's proposed solution doesn't work well in all cases. It works well if you have focused the Textarea, but if you click somewhere else and you press enter, you can still select new entries in the list that is hidden in the previous page:

Screen.Recording.2023-05-05.at.2.29.58.PM.mov

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~016a25a3c41bc6b912

[melvin-bot]

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

[melvin-bot]

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

[melvin-bot]

Current assignee @aldo-expensify is eligible for the External assigner, not assigning anyone new.

[hellohublot]

Proposal

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

Enter key isn’t creating new line for new members invitation message textinput

What is the root cause of that problem?

Because the BaseOptionsSelector is still listening for the Enter key, so line breaks have no effect

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

It may not be practical to override KeyboardShortcut, because there are some global listeners,
So we can wrap a withNavigationFocus to BaseOptionsSelector like Button,
Then we can add a parameter isEnabledFunction = () => this.props.isFocused to KeyboardShortcut.subscribe,
Then we return true if (isEnabledFunction()) in bindHandlerToKeydownEvent.every

I also suggest that we refactor KeyboardShortcut.subscribe to only have one parameter {}, because it has too many parameters, change it to one {}, and then we will know what to pass from the key, otherwise we will be confused what parameters to pass

[aldo-expensify]

I also suggest that we refactor KeyboardShortcut.subscribe to only have one parameter {}, because it has too many parameters, change it to one {}, and then we will know what to pass from the key, otherwise we will be confused what parameters to pass

While I agree that it would be better that way, I think we should keep it out of the scope of this issue. If you want to pursue this change, I think it would be good to propose it in slack.

[aldo-expensify]

I'll give some time to @rushatgabhane to check the @hellohublot 's proposal. It make sense to me, but I haven't tested it yet.

[melvin-bot]

⚠️ Looks like this issue was linked to a Deploy Blocker here

If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.

If a regression has occurred and you are the assigned CM follow the instructions here.

If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future.

[rushatgabhane]

It may not be practical to override KeyboardShortcut

@hellohublot @aldo-expensify we can set the priority of keyboard shortcuts if I'm not wrong. Maybe we should use that?

App/src/libs/KeyboardShortcut/index.js

Line 110 in 144979b

* @param {Number} [priority] The position the callback should take in the stack. 0 means top priority, and 1 means less priority than the most recently added.

[hellohublot]

@rushatgabhane Thanks for your suggestion, I tested [0, 1, -1], it doesn't work, because this only affects the order of multiple event callbacks, these events will still be executed

App/src/libs/KeyboardShortcut/index.js

Lines 123 to 130 in 144979b

	eventHandlers[displayName].splice(priority, 0, {
	id: callbackID,
	callback,
	captureOnInputs,
	shouldPreventDefault,
	shouldBubble,
	excludedNodes,
	});

[sakluger]

Sounds good - I've added the hold and moved to weekly while we wait for the other issue.

[sakluger]

Still on hold for #20353.

[aldo-expensify]

Same ^

[sakluger]

Still on hold.

[aldo-expensify]

Still on hold.

[aldo-expensify]

Same ^

[aldo-expensify]

@koko57 seems like #20353 is finished, should we remove the HOLD here and investigate what needs to be done?

[koko57]

@aldo-expensify yeah, of course! I think we should get back to it. 🙂

[koko57]

Cannot recreate either on staging or prod

Screen.Recording.2023-09-11.at.18.11.04.mov

[aldo-expensify]

@koko57 thanks for testing, I also tried now and it is working for me aswell

Screen.Recording.2023-09-12.at.9.39.34.AM.mov

Should we just close this then?

[koko57]

@aldo-expensify If you're asking me, I think yes, it can be closed now 😃

[aldo-expensify]

@aldo-expensify If you're asking me, I think yes, it can be closed now 😃

thanks! I guess I was looking for a second opinion to confirm, closing then.