[$1000] IOS - When using multiple lines for the Welcome message, after saving and returning, the app scrolls

[lanitochka17]

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.2.94.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: Applause - Internal Team
Slack conversation:

Issue found when executing PR #30238

Action Performed:

1. Log in with any acccount
2. Go to #announce or #admins chat
3. Click on header > Details > Settings > Welcome message
4. Use multiple lines for Welcome message
5. Save it
6. Go back to Welcome message again

Expected Result:

When using multiple lines for the Welcome message, after saving and returning, the app should not scroll the message from the top to the bottom

Actual Result:

When using multiple lines for the Welcome message, after saving and returning, the app scrolls the message from the top to the bottom

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

Bug6259537_1698852395381.RPReplay_Final1698850932__1_.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~016160035c97c0cabe
• Upwork Job ID: 1719740731830575104
• Last Price Increase: 2023-11-27

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~016160035c97c0cabe

[melvin-bot]

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

[melvin-bot]

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

[melvin-bot]

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

[ikevin127]

Other issues / discussions related to similar behaviour on iOS:
#28790
#20836

Proposal

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

When using multiple lines for the Welcome message, after saving and returning back to editing, the app scrolls the multi-line input from the top to the bottom.

What is the root cause of that problem?

There's a race condition between useFocusEffect which calls welcomeMessageInputRef.current.focus() with a timeout of 300ms and the updateMultilineInputRange() which is called right after setting the TextInput's ref.

Why I'm saying this ? Because when commenting out updateMultilineInputRange(), the bug described in this issue can be reproduced with 100% success rate:

iOS: Native - Issue reproduced 100% rate

Screen.Recording.2023-11-08.at.13.57.43.mov

Note: the current implementation is also problematic on MacOS: Firefox, where the input does get focused but there's a scroll glitch and no scrolling is performed.

MacOS: Firefox

Screen.Recording.2023-11-17.at.01.44.42.mov

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

Considering the latest observations / suggestions from #30707 (comment), in order to ensure that we focus the input, as soon as possible, ensuring the cursor is at the end for both iOS and all other platforms, I'm proposing the following changes:

Update the @libs/UpdateMultilineInputRange/index.js function to use currently unused shouldFocusInput prop and adding additional prop shouldDelay in order to ensure the functionality on web works as expected:

Updated @libs/UpdateMultilineInputRange/index.js

+ import CONST from "@src/CONST";

+ let timeoutID = null;
/**
 * Place the cursor at the end of the value (if there is a value in the input).
 *
 * When a multiline input contains a text value that goes beyond the scroll height, the cursor will be placed
 * at the end of the text value, and automatically scroll the input field to this position after the field gains focus.
 * This provides a better user experience in cases where the text in the field has to be edited. The auto-
 * scroll behaviour works on all platforms except iOS native.
 * See https://github.com/Expensify/App/issues/20836 for more details.
 *
 * @param {Object} input the input element
 * @param {boolean} shouldAutoFocus
 * @param {boolean} shouldDelay
 */
- // eslint-disable-next-line no-unused-vars
- export default function updateMultilineInputRange(input, shouldAutoFocus = true) {
+ export default function updateMultilineInputRange(input, shouldAutoFocus = false, shouldDelay = false) {
    const setCursorToEnd = () => {
        if (!input) {
            return;
        }

+       if (shouldAutoFocus) {
+           input.focus();
+       }

+       // The selection set has to be called after the focus, otherwise it will not work on Firefox
        if (input.value && input.setSelectionRange) {
            const length = input.value.length;
            input.setSelectionRange(length, length);
            // eslint-disable-next-line no-param-reassign
            input.scrollTop = input.scrollHeight;
        }
    };

+   // Clear the timeout if it's already been set to prevent multiple invocations
+   if (timeoutID !== null) {
+       clearTimeout(timeoutID);
+       timeoutID = null;
+   }

+   if (shouldDelay) {
+       timeoutID = setTimeout(setCursorToEnd, CONST.ANIMATED_TRANSITION);
+   } else {
+       setCursorToEnd();
+   }
}

• shouldFocusInput default was set to false to ensure backwards compatibility
• by adding shouldDelay logic we ensure that the implementation works the same on all platforms (incl. Firefox web)

@libs/UpdateMultilineInputRange/index.ios.js remains unchanged because we need the focus() without delay to be called as soon as possible.

With this update to the function, the final code will look like this:

// src/pages/ReportWelcomeMessagePage.js

        ref={(el) => {
            if (!el) {
                return;
            }
            welcomeMessageInputRef.current = el;
-           updateMultilineInputRange(welcomeMessageInputRef.current);
+           updateMultilineInputRange(welcomeMessageInputRef.current, true, true);
        }}

and the useFocusEffect block will be completely removed from the component as it won't be needed anymore.

Note:

considering that the same code using both updateMultilineInputRange() and useFocusEffect code block are used in quite a few other instances with the same component type, we can update all those components updateMultilineInputRange() function as well and delete all useFocusEffect code block instances once updated.

What alternative solutions did you explore?

Keeping the updateMultilineInputRange() implementation as it is but replace the useFocusEffect code block with a updated version of the useDelayedInputFocus hook that will target all platforms except iOS (return null), using platform dependent files like so:

@hooks/useDelayedInputFocus/index.ts

import {useRef, useEffect,} from 'react';
import CONST from '@src/CONST';
import { getBrowser } from '@libs/Browser';
import updateMultilineInputRange from '@libs/UpdateMultilineInputRange';

/**
 * Focus a text input when a screen is navigated to, after the specified time delay has elapsed.
 */
export default function useDelayedInputFocus(inputRef: React.RefObject<HTMLInputElement>, delay: number = CONST.ANIMATED_TRANSITION) {
    const timeoutRef = useRef<NodeJS.Timeout | null>(null);

    useEffect(() => {
        timeoutRef.current = setTimeout(() => {
            if (!inputRef.current) {
                return;
            }
            inputRef.current.focus();
            if (getBrowser() === CONST.BROWSER.FIREFOX) {
                updateMultilineInputRange(inputRef.current);
            }
        }, delay);
        return () => {
            if (!timeoutRef.current) {
                return;
            }
            clearTimeout(timeoutRef.current);
        };
    // eslint-disable-next-line react-hooks/exhaustive-deps
    }, []);
}

• we setTimeout, calling focus() and only calling updateMultilineInputRange() again for Firefox to make sure selection will be at the end of last word
• @hooks/useDelayedInputFocus/index.ios.ts returns null because we don't need to focus again since updateMultilineInputRange() right after the ref does that because of the platform specific index.ios.js version of the function

By calling this hook instead of the useFocusEffect code block, together with updateMultilineInputRange() right after the ref is set we achieve the same result as the first solution.

Note:

considering this alternative method's implementation, all useFocusEffect code block instances from the other components can be replaced with this hook ensuring consistent behaviour.

Videos

iOS: Native

Screen.Recording.2023-11-02.at.00.37.09.mov

MacOS: Firefox

Screen.Recording.2023-11-17.at.02.26.56.mov

[ikevin127]

Updated proposal

• changed in order to ensure the fix results in the same behaviour on all platforms

[isabelastisser]

Hey @cubuspl42, can you please review the proposal above? Thanks!