[$250] mweb/Chrome - Chat - Edit message after sending attachment, composer box isn't fit on screen

[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: 9.1.73-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: N/A
Email or phone of affected tester (no customers): gmail account
Issue reported by: Applause - Internal Team

Action Performed:

1. Open https://staging.new.expensify.com/
2. Go to any chat
3. Type anything for 5 lines and send message
4. Send an attachment
5. Hold the message at step 3 for open menu
6. Tap Edit comment

Expected Result:

Edit composer should fit on screen

Actual Result:

Depend on size of attachment, edit composer is cut off by the header

Workaround:

Unknown

Platforms:

Select the officially supported platforms where the issue was reproduced:

• Android: App
• Android: mWeb Chrome
• iOS: App
• iOS: mWeb Safari
• iOS: mWeb Chrome
• Windows: Chrome
• MacOS: Chrome / Safari
• MacOS: Desktop

Platforms Tested:

On which of our officially supported platforms was this issue tested:

• Android: App
• Android: mWeb Chrome
• iOS: App
• iOS: mWeb Safari
• iOS: mWeb Chrome
• Windows: Chrome
• MacOS: Chrome / Safari
• MacOS: Desktop

Screenshots/Videos

Add any screenshot/video evidence

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021940993162951905956
• Upwork Job ID: 1940993162951905956
• Last Price Increase: 2025-09-12

Issue Owner

Current Issue Owner: @dominictb

[melvin-bot]

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

[Eskalifer1]

I think the reason for the bug is that we currently don't have the scroll to element with composer focus working correctly

2025-07-03.00.36.45.mov

Here are one of the two: Either it's a regression from some change that was overlooked or it's after some library was updated, because a task was created for this earlier and that part of the code is still here:

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

Lines 478 to 480 in 98503fe

	if (isMobileChrome() && reportScrollManager.ref?.current) {
	reportScrollManager.ref.current.scrollToIndex({index, animated: false});
	}

This is the PR: #56079

As you can see from the screenshots, it worked at that moment

In general, as for me, the main problem here is that on Android mweb the keyboard appears almost instantly when the field is focused. This is the default behavior and we probably can't override it. If you compare it with other environments, you can see that the scroll happens first, and only then the keyboard appears.

Therefore, it would be possible to scroll for isMobileChrome after the keyboard appears, but the problem here is that there are no such methods natively, so we will have to proably use setTimeout, but I think it's better to discuss this issue

[bernhardoj]

Proposal

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

The edit message out of screen a bit when editing it after adding an attachment.

What is the root cause of that problem?

When we edit the message, a scroll to bottom is called because the list onLayout is triggered and isScrollToBottomEnabled is true.

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

Lines 633 to 639 in 9e3b5bd

	const onLayoutInner = useCallback(
	(event: LayoutChangeEvent) => {
	onLayout(event);
	if (isScrollToBottomEnabled) {
	reportScrollManager.scrollToBottom();
	setIsScrollToBottomEnabled(false);
	}

isScrollToBottomEnabled is true when there is a new action and we want to scroll to bottom.

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

Line 431 in 9e3b5bd

setIsScrollToBottomEnabled(true);

It was added in #57901 with the assumption that the list onLayout will trigger everytime a new item is added to the list. However, in our case, after adding the attachment, the onLayout isn't triggered, so isScrollToBottomEnabled stays true, and when editing the message, the onLayout is triggered, and because isScrollToBottomEnabled is true, the scroll to bottom happens.

Invoked on mount and on layout changes.

From the React docs, onLayout is triggered only on mount and layout changes. The onLayout is triggered when we edit a message because the main composer hides, causing the list position to change. We can't rely on this to check if a new item is added or not.

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

The issue that #57901 is trying to solve only happens on iOS Chrome. I can't test it there, but if it's not happening anymore, then we can simply revert it. Otherwise,

we can use a more reliable approach by using onContentSizeChange instead of onLayout.

onContentSizeChange={() => {
    if (isScrollToBottomEnabled) {
        reportScrollManager.scrollToBottom();
        setIsScrollToBottomEnabled(false);
    }
}}

(we can consider changing isScrollToBottomEnabled to a ref to avoid unnecessary render)

note that I can't test this on iOS Chrome, so I need the C+ to verify this.

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

N/A

[dmkt9]

Proposal

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

Depend on size of attachment, edit composer is cut off by the header

What is the root cause of that problem?

• When the user adds a comment, isScrollToBottomEnabled is set to true by:
  

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

  Line 431 in 9e3b5bd

  setIsScrollToBottomEnabled(true);

• This causes the layout change triggered by editing a comment to invoke the code below:
  

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

  Lines 633 to 642 in 9e3b5bd

  	const onLayoutInner = useCallback(
  	(event: LayoutChangeEvent) => {
  	onLayout(event);
  	if (isScrollToBottomEnabled) {
  	reportScrollManager.scrollToBottom();
  	setIsScrollToBottomEnabled(false);
  	}
  	},
  	[isScrollToBottomEnabled, onLayout, reportScrollManager],
  	);

  
  Since isScrollToBottomEnabled === true, the chat view scrolls to the bottom.

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

Ensure that scrolling to the bottom is not triggered when the composer is focused during an edit:

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

Line 636 in 9e3b5bd

if (isScrollToBottomEnabled) {

const isEditComposerFocused = ReportActionComposeFocusManager.isEditFocused();
if (isEditComposerFocused) {
    setIsScrollToBottomEnabled(false);
    return;
}
if (isScrollToBottomEnabled) { ...

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

NA

What alternative solutions did you explore? (Optional)

NA

Reminder: Please use plain English, be brief and avoid jargon. Feel free to use images, charts or pseudo-code if necessary. Do not post large multi-line diffs or write walls of text. Do not create PRs unless you have been hired for this job.

[melvin-bot]

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

[melvin-bot]

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

[ikevin127]

♻ Reviewing proposals...