iOS - Edit composer is hidden behind keyboard when editing message

[IuliiaHerets]

If you haven’t already, check out our contributing guidelines for onboarding and email [email protected] to request to join our Slack channel!

---

Version Number: 9.0.80-1
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught on HybridApp, is this reproducible on New Expensify Standalone?: Yes, reproducible on both
If this was caught during regression testing, add the test name, ID and link from TestRail: Exp
Email or phone of affected tester (no customers): [email protected]
Issue reported by: Applause Internal Team
Device used: iPhone 15 Pro Max / iOS 18.2
App Component: Chat Report View

Action Performed:

1. Launch ND or hybrid app.
2. Go to any chat that is scrollable.
3. Send a message.
4. Swipe down on the composer to dismiss the keyboard.
5. Long tap on the message > Edit comment.

Expected Result:

The edit composer will scroll to above the keyboard so that the edit composer is visible when editing the message.

Actual Result:

The edit composer is hidden behind keyboard.

Workaround:

Unknown

Platforms:

• Android: Standalone
• Android: HybridApp
• Android: mWeb Chrome
• iOS: Standalone
• iOS: HybridApp
• iOS: mWeb Safari
• MacOS: Chrome / Safari
• MacOS: Desktop

Screenshots/Videos

Bug6704735_1735705105702.ScreenRecording_01-01-2025_12-18-00_1.mp4

View all open jobs on GitHub

[melvin-bot]

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

[melvin-bot]

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

💬 A slack conversation has been started in #expensify-open-source

[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.

[Beamanator]

Seems likely that this is related to #42143 🤔 - posted in slack thread

• cc @kirillzyusko @roryabraham @rojiphil @shubham1206agra @luacmartins

[rojiphil]

Seems likely that this is related to #42143

Just checked but It does not look like it is related to this and I cannot reproduce it as well. Or maybe we need more information to reproduce.

42143-ios-st-no-rep.mp4

[truph01]

Proposal

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

• The edit composer is hidden behind keyboard.

What is the root cause of that problem?

• When focusing on the edit comment composer, we use the following logic:

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

Lines 528 to 532 in 754817d

	InteractionManager.runAfterInteractions(() => {
	requestAnimationFrame(() => {
	reportScrollManager.scrollToIndex(index, true);
	});
	});

This logic is intended to scroll to the editing message after the keyboard is displayed. However, using InteractionManager.runAfterInteractions does not guarantee that the keyboard is fully visible before calling reportScrollManager.scrollToIndex(index, true).

• The bug occurs inconsistently and is not easily reproducible.

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

• We can wait for the keyboard to be fully displayed before scrolling. To achieve this, we can use:

const keyboardDidShowListener = Keyboard.addListener('keyboardDidShow', (e) => {
                                    reportScrollManager.scrollToIndex(index, true);
                                    keyboardDidShowListener.remove();
                                });

instead of the current logic.

• We could consider applying the logic separately for web and native platforms. On the web, we can retain the current logic, while for native, we could implement the updated approach. However, since editing on the web does not involve scrolling, it seems unnecessary to make any changes there.

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

What alternative solutions did you explore? (Optional)

[rojiphil]

On spending some more time on testing, I notice that the edit composer does get covered to some extent although I do not see it covered completely as described in the issue. But seems like solving it would also solve the issue here. Also, I notice quick jump up and down instead of a smooth one.
@kirillzyusko Do you also notice this?

42143-ios-st-rep.mp4

[kirillzyusko]

@rojiphil In my case it's reproducible only in release variant. In debug everything works well 🤷‍♂️

Will try to search for a solution 👀

[Beamanator]

Seems like the PR was reverted 😅

[kirillzyusko]

Seems like the PR was reverted 😅

Unfortunately 😔

[Beamanator]

Can't reproduce anymore due to revert 👍 🤷