[HOLD for payment 2024-08-29] [$250] Composer box- position cursor jumps to begining of message when copying as link

[izarutskaya]

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.11-2
Reproducible in staging?: Y
Reproducible in production?: Y
Email or phone of affected tester (no customers): negasofonias+7241@gmail.com
Logs: https://stackoverflow.com/c/expensify/questions/4856
Issue reported by: Applause-Internal team

Action Performed:

1. Login to staging new dot
2. Go to any chat with history and type anything in the composer
3. While still in edit mode long press any message from chat and select copy as link
4. observe that the position cursor in composer box jumps to the begining of the content in the composer box

Expected Result:

Position cursor should stay at the end of the message being typed

Actual Result:

Position cursor jumps to the front of the content being typed

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

Bug6550361_1721724352651.Screen_Recording_20240723_113515.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~01dc75491f30967e9c
• Upwork Job ID: 1816958403568861454
• Last Price Increase: 2024-08-09
• Automatic offers:
• c3024 | Reviewer | 103552362

Issue Owner

Current Issue Owner: @c3024

[melvin-bot]

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

[izarutskaya]

We think this issue might be related to the #vip-vsb

[bernhardoj]

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

Proposal

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

The cursor position of the composer go to the start after selecting option from the context menu.

What is the root cause of that problem?

When we select an option from the context menu such as copy link, we will refocus to the composer.

App/src/pages/home/report/ContextMenu/ContextMenuActions.tsx

Line 459 in bf69d5d

hideContextMenu(true, ReportActionComposeFocusManager.focus);

ReportActionComposeFocusManager.focus will trigger ReportActionComposeFocusManager.onComposerFocus callback that is set up in ComposerWithSuggestions and Composer/index.tsx.

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

Lines 589 to 595 in bf69d5d

	ReportActionComposeFocusManager.onComposerFocus((shouldFocusForNonBlurInputOnTapOutside = false) => {
	if ((!willBlurTextInputOnTapOutside && !shouldFocusForNonBlurInputOnTapOutside) || !isFocused) {
	return;
	}
	focus(false);
	}, true);

App/src/components/Composer/index.tsx

Lines 376 to 386 in bf69d5d

	onFocus={(e) => {
	ReportActionComposeFocusManager.onComposerFocus(() => {
	if (!textInput.current) {
	return;
	}
	textInput.current.focus();
	});
	props.onFocus?.(e);
	}}

I don't have the context on why we have 2 onComposerFocus, but the 2nd onComposerFocus is only set-up when the composer is focused and also being used for both main and edit composer.

When the composer (live markdown input) is focused, it will trigger onFocus of the live markdown div element (which triggers handleFocus) then set the cursor position based on the selection value.
https://github.com/Expensify/react-native-live-markdown/blob/ff55579f673c049a6eb6cdf38ffc223315309b07/src/MarkdownTextInput.web.tsx#L502-L516

However, in our case, focusing after closing the context menu doesn't trigger the onFocus event so the cursor position is never set. I found that it's caused by the focus trap. When we try to focus the composer (from onModalHide callback), the modal isn't completely hidden and the focus trap isn't completely deactivated yet.

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

We need to wait for the modal to completely hidden before focusing the composer. If the modal is completely hidden, the children will be unmounted including the focus trap too, so it's guaranteed the focus trap is gone. To do that, we need to focus to the composer using focusComposerWithDelay and enable the "delay". The "delay" is not a timeout but rather a promise indicating whether it's ready to focus on the composer or not. (note: the old implementation rely on timeout)

App/src/libs/focusComposerWithDelay/index.ts

Lines 30 to 34 in bf69d5d

	Promise.all([ComposerFocusManager.isReadyToFocus(), isWindowReadyToFocus()]).then(() => {
	if (!textInput) {
	return;
	}
	textInput.focus();

ReportActionComposeFocusManager.onComposerFocus(() => {
    ...
    focusComposerWithDelay(textInput.current)(true);
});

isWindowReadyToFocus is android only, so we can ignore it. The ComposerFocusManager.isReadyToFocus() is resolved when the modal is completely hidden. It's resolved from the onDismiss callback here.

App/src/components/Modal/BaseModal.tsx

Line 232 in bf69d5d

onDismiss={handleDismissModal}

App/src/components/Modal/BaseModal.tsx

Lines 145 to 147 in bf69d5d

	const handleDismissModal = () => {
	ComposerFocusManager.setReadyToFocus(uniqueModalId);
	};

However, in strict mode, the onDismiss is triggered when the modal becomes visible, so isReadyToFocus is already resolved. To fix that, we need to add a onModalWillShow prop which calls saveFocusState to ModalContent too. Then, in ModalContent, call onModalWillShow on mount.

<ModalContent 
    onModalWillShow={saveFocusState}
    onDismiss={handleDismissModal}
>

ModalContent.tsx

React.useEffect(() => {
    onModalWillShow();
    return onDismiss;
}, []);

This will fix the issue when we previously focus on the composer, open the context menu, and select copy link. However, it's still broken if we open the chat without focusing on the composer, open the context menu, and select copy link. As I mentioned in my proposal, the cursor position is set based on the selection value. The main composer initial selection value is 0, so without ever focusing on the composer, selecting copy link from the context menu will still put the cursor at the start. To fix it, we need to set the initial selection to the value length.

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

Line 301 in bf69d5d

const [selection, setSelection] = useState<TextSelection>(() => ({start: 0, end: 0, positionX: 0, positionY: 0}));

const [selection, setSelection] = useState(() => ({start: value.length, end: value.length, positionX: 0, positionY: 0}));

[melvin-bot]

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

[melvin-bot]

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