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

@dominictb

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:

Open https://staging.new.expensify.com/
Go to any chat
Type anything for 5 lines and send message
Send an attachment
Hold the message at step 3 for open menu
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:

Platforms Tested:

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

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

@lydiabarclay

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.

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

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

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.

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

@ikevin127

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

I'm still catching up with context on this one.

@s77rt

I agree with @s77rt opinion here that the root cause for #57379 was not correct and we should revert that PR then find the correct root cause for it instead. Reseting that state in some specific cases seems like a workaround. Still looking for a proposal with correct RCA.

@dominictb

@dominictb Yes, we can revert the isScrollToBottomEnabled flag and use requestAnimationFrame(() => { reportScrollManager.scrollToBottom(); }); to trigger the scroll action in the next available frame, specifically for Safari.

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

Line 458 in 8ebed90

setIsScrollToBottomEnabled(true);

update to:

requestAnimationFrame(() => { reportScrollManager.scrollToBottom(); });

Screen.Recording.2025-09-04.at.08.32.20.mov

📣 It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? 💸

Issue not reproducible during KI retests. (Second week)

@dominictb

@dominictb Huh... This is 4 days overdue. Who can take care of this?

📣 It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? 💸

@dominictb

@dominictb 8 days overdue is a lot. Should this be a Weekly issue? If so, feel free to change it!

Issue not reproducible during KI retests. (Third week)

@dominictb

Hey @dominictb QA was unable to reproduce over the course of three weeks of re-tests. I'm going to go ahead and close this.

Navigation Menu

Repository navigation

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

Action Performed:

Expected Result:

Actual Result:

Workaround:

Platforms:

Screenshots/Videos

Proposal

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

What is the root cause of that problem?

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

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

Proposal

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

What is the root cause of that problem?

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

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

What alternative solutions did you explore? (Optional)

108 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

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

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

Description

Action Performed:

Expected Result:

Actual Result:

Workaround:

Platforms:

Screenshots/Videos

Activity

melvin-bot commented on Jul 2, 2025

Eskalifer1 commented on Jul 2, 2025

bernhardoj commented on Jul 3, 2025

Proposal

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

What is the root cause of that problem?

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

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

dmkt9 commented on Jul 3, 2025

Proposal

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

What is the root cause of that problem?

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

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

What alternative solutions did you explore? (Optional)

melvin-bot commented on Jul 4, 2025

melvin-bot commented on Jul 4, 2025

ikevin127 commented on Jul 5, 2025

108 remaining items

dominictb commented on Sep 3, 2025

dominictb commented on Sep 3, 2025

huult commented on Sep 4, 2025

melvin-bot commented on Sep 5, 2025

mvtglobally commented on Sep 5, 2025

melvin-bot commented on Sep 8, 2025

melvin-bot commented on Sep 12, 2025

melvin-bot commented on Sep 12, 2025

mvtglobally commented on Sep 13, 2025

lydiabarclay commented on Sep 15, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions