[$250] Expense - Unable to create a new line in description field with SHIFT+ENTER

[IuliiaHerets]

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

---

Version Number: v9.0.25-0
Reproducible in staging?: Y
Reproducible in production?: N
Email or phone of affected tester (no customers): applausetester+kh050806@applause.expensifail.com
Issue reported by: Applause Internal Team

Action Performed:

1. Go to staging.new.expensify.com
2. Go to chat.
3. Click + > Submit expense > Manual.
4. Enter amount > Next.
5. Click Description.
6. Enter some text, then press SHIFT+ENTER (enter key for mweb).

Expected Result:

A new line will be created with SHIFT+ENTER.

Actual Result:

A new line is not created with SHIFT+ENTER. The description is saved instead.

This issue happens in IOU, task and room description.

Workaround:

Unknown

Platforms:

• Android: Native
• Android: mWeb Chrome
• iOS: Native
• iOS: mWeb Safari
• MacOS: Chrome / Safari
• MacOS: Desktop

Screenshots/Videos

Bug6583767_1724725007695.20240827_101239.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~0140f764621c9cb74a
• Upwork Job ID: 1828427517631808725
• Last Price Increase: 2024-08-27

Issue Owner

Current Issue Owner: @s77rt

[melvin-bot]

Triggered auto assignment to @kadiealexander (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

[melvin-bot]

Triggered auto assignment to @Gonals (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

[IuliiaHerets]

We think that this bug might be related to #wave-collect - Release 1

[github-actions]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[Gonals]

I don't think this needs to be a blocker, as it is a fairly minor bug.

@bernhardoj, I think this may have been caused by #46172. Could you take a look?

[bernhardoj]

I don't think it's caused by that PR since that's deployed to prod a month ago.

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~0140f764621c9cb74a

[melvin-bot]

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

[bernhardoj]

Edited by proposal-police: This proposal was edited at 2024-08-27 14:27:45 UTC.

Proposal

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

Pressing SHIFT+ENTER submit the description instead of adding new line.

What is the root cause of that problem?

The page has an ENTER shortcut enabled by default (from the Form) and there is a condition to disable the shortcut if the active element role is in the CONST.ROLE list and not a PRESENTATION role.

App/src/components/Button/index.tsx

Lines 140 to 146 in db1c4c2

	const accessibilityRoles: string[] = Object.values(CONST.ROLE);
	function KeyboardShortcutComponent({isDisabled = false, isLoading = false, onPress = () => {}, pressOnEnter, allowBubble, enterKeyEventListenerPriority}: KeyboardShortcutComponentProps) {
	const isFocused = useIsFocused();
	const activeElementRole = useActiveElementRole();
	const shouldDisableEnterShortcut = useMemo(() => accessibilityRoles.includes(activeElementRole ?? '') && activeElementRole !== CONST.ROLE.PRESENTATION, [activeElementRole]);

The description ROLE is actually PRESENTATION,

App/src/pages/iou/request/step/IOURequestStepDescription.tsx

Line 178 in db1c4c2

role={CONST.ROLE.PRESENTATION}

but the live markdown input only accepts accessibilityRole props and fallback to "textbox",
https://github.com/Expensify/react-native-live-markdown/blob/356f4b46b78734ee28ed75d6f51902e754065406/src/MarkdownTextInput.web.tsx#L647

so in the end, the role of the input becomes "textbox". However, "textbox" doesn't exist in CONST.ROLE. It was previously existed in CONST.ACCESSIBILITY_ROLE but we remove ACCESSIBILITY_ROLE in favor of ROLE in #47705.

This doesn't happen in a non-live markdown multiline text because we already ignore it as shown here.

App/src/components/Button/validateSubmitShortcut/index.ts

Lines 12 to 16 in 6ca91cd

	const validateSubmitShortcut: ValidateSubmitShortcut = (isDisabled, isLoading, event) => {
	const eventTarget = event?.target as HTMLElement;
	if (isDisabled || isLoading || eventTarget.nodeName === 'TEXTAREA') {
	return false;
	}

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

Add "textbox" back to CONST.ROLE.

There are a few roles that exist in CONST.ACCESSIBILITY_ROLE but not in CONST.ROLE. Perhaps we can re-add them all.

---

Unrelated to the solutions.

but the live markdown input only accepts accessibilityRole props

Regarding this one, maybe we can update it to accept role instead since all text input in the app passes role instead of accessibilityRole, except on the console page which we can update.

But actually, if we see the doc here, it's mentioned that it's better to use input with type text or textarea instead of using role. The input in our app already uses those tags, except live markdown which needs to use a div with the role of textbox. So, it's better if we remove all role props from all input.

[s77rt]

@bernhardoj Thanks for the proposal. I think this one should be fixed by the PR author given it's a new regression #47705. cc @Krishna2323 @ZhenjaHorbach

[ZhenjaHorbach]

Oh
Yeah
This is ours !
@Krishna2323
Could you raise the PR please?

[Krishna2323]

@ZhenjaHorbach, will raise the PR within an hour.

[bernhardoj]

Since the help wanted label is added, I think we can apply my solution instead of reintroducing deprecated ACCESSIBILITY_ROLE constant and also applying additional changes from my proposal.

[s77rt]

@bernhardoj

Add "textbox" back to CONST.ROLE.

The textbox is not a valid role value according to this list

the live markdown input only accepts accessibilityRole props. Regarding this one, maybe we can update it to accept role instead

This makes sense but it won't fix the problem as if we do that now the role will be presentation and the enter shortcut will still not be disabled

[bernhardoj]

The textbox is not a valid role value according to this list

Looks like it's different between RN and RN-web since RN-web supports all ARIA roles. Maybe on native, it's not explicitly needed to set the role to an input, similar to web where it's recommended to use input without any role.

as if we do that now the role will be presentation and the enter shortcut will still not be disabled

Yes, that's why I suggest this.

But actually, if we see the doc here, it's mentioned that it's better to use input with type text or textarea instead of using role. The input in our app already uses those tags, except live markdown which needs to use a div with the role of textbox. So, it's better if we remove all role props from all input.

[s77rt]

@bernhardoj If we remove the role prop from all input, including single-line inputs, then the enter key press won't be captured but it's needed in that case.

[melvin-bot]

This issue has not been updated in over 15 days. @s77rt, @Gonals, @kadiealexander eroding to Monthly issue.

P.S. Is everyone reading this sure this is really a near-term priority? Be brave: if you disagree, go ahead and close it out. If someone disagrees, they'll reopen it, and if they don't: one less thing to do!

[s77rt]

@kadiealexander @Gonals Let's close this. Fixed on #48128