[$250] Comment not deleted when delete button in red and hit enter key

[m-natarajan]

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: 1.4.76-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
Expensify/Expensify Issue URL:
Issue reported by: @iwiznia
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1716823498553919

Action Performed:

1. Go to staging.new.expensify.com and login
2. Send a message to anyone
3. Edit the message by right clicking
4. Delete the message and press "Enter"
5. Press "Enter" again

Expected Result:

Message/comment deleted

Actual Result:

Message/comment is not deleted because the focus is on the cancel button (even though delete is in red)

Workaround:

Unknown

Platforms:

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

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

Screenshots/Videos

Add any screenshot/video evidence

Recording.128.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~01b70ac798adfe8d66
• Upwork Job ID: 1795470513005948928
• Last Price Increase: 2024-05-28
• Automatic offers:
• bernhardoj | Contributor | 102543808

Issue Owner

Current Issue Owner: @sobitneupane

[melvin-bot]

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

[dragnoir]

Proposal

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

Comment not deleted when delete button in red and hit enter key

What is the root cause of that problem?

Needs focus trap

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

After this PR merged #39520

We need to use focus trap to set the focus inside the delete popup and to set the focus to the delete button

What alternative solutions did you explore?

To set focus on the button when the component loads, we can use the useRef hook to create a reference to the button and then use the useEffect hook to focus it once the component has mounted. Here's how you can modify the ConfirmContent component to achieve this:

1. Import the useRef and useEffect hooks from React.
2. Create a reference using useRef.
3. Apply the reference to the button.
4. Use useEffect to set the focus when the component loads.

Here's the updated code:

const confirmButtonRef = useRef(null); // Create a ref for the confirm button

useEffect(() => { if (confirmButtonRef.current) { confirmButtonRef.current.focus(); // Focus the confirm button when the component loads } }, []);

<Button  ref={confirmButtonRef} //..

In this updated code, the confirmButtonRef is used to create a reference to the confirm button, and useEffect is used to set the focus on the button when the component loads.

[bernhardoj]

Proposal

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

Pressing the Enter key when opening the delete confirmation modal doesn't delete the comment/message.

What is the root cause of that problem?

When the delete confirmation modal is shown, the focus trap from the rn-web Modal focuses on the Cancel button, so pressing Enter will press the Cancel button. We set pressOnEnter shortcut to the Delete button, but it will be disabled if the current focus is focused on an element with an accessibility role, except text.

App/src/components/Button/index.tsx

Line 131 in 2514f29

const shouldDisableEnterShortcut = useMemo(() => accessibilityRoles.includes(activeElementRole ?? '') && activeElementRole !== CONST.ACCESSIBILITY_ROLE.TEXT, [activeElementRole]);

Now, the question is why the cancel button is focused first when we open the confirmation modal. In the confirmation modal, there are 3 focusable elements, the overlay, delete button, and cancel button. The logic of the focus trap is here. It will focus on the first focusable element first and keep the focus when tabbing within the focus trapped element.

Here is how it behaves in this GH test case. First, it will focus on the first focusable descendant of the modal, in our case, it's the modal overlay. The modal overlay is saved as the last focused element. At this point, the edit composer is blurred. If the edit composer is blurred, it will set SHOULD_SHOW_COMPOSE_INPUT to true.

App/src/pages/home/report/ReportActionItemMessageEdit.tsx

Line 427 in 2514f29

setShouldShowComposeInputKeyboardAware(true);

SHOULD_SHOW_COMPOSE_INPUT hides the main composer when an edit composer is focused, on small screens only. Besides the SHOULD_SHOW_COMPOSE_INPUT controls the main composer visibility, it also controls the autoFocus behavior.

App/src/pages/home/report/ReportActionCompose/ComposerWithSuggestions/ComposerWithSuggestions.tsx

Lines 288 to 289 in 2514f29

	const shouldAutoFocus =
	!modal?.isVisible && isFocused && (shouldFocusInputOnScreenFocus || (isEmptyChat && !ReportActionsUtils.isTransactionThread(parentReportAction))) && shouldShowComposeInput;

Because SHOULD_SHOW_COMPOSE_INPUT is now true, autoFocus now becomes true too. Before, it was false because an edit composer was focused which set SHOULD_SHOW_COMPOSE_INPUT to false.

Now, here's the problem. autoFocus is supposed to work only once when the text input is mounted. However, the live markdown input will focus on the input every time the autoFocus is changed to true.
https://github.com/Expensify/react-native-live-markdown/blob/main/src/MarkdownTextInput.web.tsx#L584-L588

The input focus then triggers the focus trap logic again which first focuses on the first focusable descendant, that is the overlay. Then it checks whether the last (prev) focused element is the same as the current focused element. If it's the same, it will start focusing on the last focusable descendant element.

In our case, the last focused element is the overlay and the first focusable descendant is also the overlay, so the focus trap will focus on the last focusable descendant element, that is the cancel button.

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

We can:

1. Update the autoFocus condition to only consider the SHOULD_SHOW_COMPOSE_INPUT value for the small screen,
2. Don't change the SHOULD_SHOW_COMPOSE_INPUT to true when the edit composer is blurred by the confirmation modal

but I would like to address the root cause of the issue, that is the input gets focused every time autoFocus is changed which doesn't happen with the react native TextInput.

To fix the issue, we should remove autoFocus from the effect deps here
https://github.com/Expensify/react-native-live-markdown/blob/377ab57fa02c598b624eb91e4faf4fd2693596a2/src/MarkdownTextInput.web.tsx#L584-L588

This way, it will work as pointed out by the comment, that is to auto-focus only when the component is mounted, not when autoFocus is changed.

This happens after this react native live markdown PR which adds the react hooks eslint rule and adds the autoFocus as the deps to fix the lint, but we shouldn't do that for autoFocus case.

This will also fix an issue where the main composer is focused every time the edit composer is blurred.

Screen.Recording.2024-05-28.at.15.55.48.mov

After this change, the overlay will be the one that is focused when opening the confirmation modal, which is what happens with other confirmation modals. Pressing Enter on the overlay will trigger the pressOnEnter shortcut because the overlay doesn't have any role.

[melvin-bot]

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

[melvin-bot]

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

[sobitneupane]

Thanks for the proposal everyone.

Proposal from @bernhardoj looks good to me.

🎀👀🎀 C+ reviewed