[$250] Chat - Compose box stays in the middle when reduced with a several lines 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.39-0
Reproducible in staging?: Y
Reproducible in production?: Y
Issue reported by: Applause Internal Team

Action Performed:

1. Open the staging.new.expensify.com website.
2. Open any chat.
3. On compose box, start writing a message adding new lines until a scrollbar can be seen.
4. Tap on the "Expand" button.
5. Keep adding lines to the message until a scrollbar can also be seen with the compose box expanded.
6. Reduce the compose box size.
7. Verify if you are scrolled to the bottom when the compose box is reduced.

Expected Result:

When the compose box with a written message of several lines is reduced in size, the user should be scrolled to the bottom of it.

Actual Result:

When the compose box with a written message of several lines is reduced in size, the user is not scrolled to the bottom. The compose box is displayed in the middle of the message.

Workaround:

Unknown

Platforms:

• Android: Native
• Android: mWeb Chrome
• iOS: Native
• iOS: mWeb Safari
• MacOS: Chrome / Safari
• MacOS: Desktop

Screenshots/Videos

Bug6609918_1726836461310.Compose_Reduce.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021838742813045152105
• Upwork Job ID: 1838742813045152105
• Last Price Increase: 2024-10-02
• Automatic offers:
• rayane-djouah | Reviewer | 104312306
• FitseTLT | Contributor | 104312308

Issue Owner

Current Issue Owner: @rayane-djouah

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

[IuliiaHerets]

We think that this bug might be related to #wave-collect - Release 1

[IuliiaHerets]

@anmurali FYI I haven't added the External label as I wasn't 100% sure about this issue. Please take a look and add the label if you agree it's a bug and can be handled by external contributors

[FitseTLT]

Proposal

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

Chat - Compose box stays in the middle when reduced with a several lines message

What is the root cause of that problem?

When we toggle isComposerFullSize there is a code that sets the scrollTop to the previous scrollTop (the scrollTop in the previous isComposerFullSize state)

App/src/components/Composer/index.tsx

Lines 268 to 271 in 25450d9

	// eslint-disable-next-line react-compiler/react-compiler
	textInput.current.scrollTop = prevScroll;
	// eslint-disable-next-line react-compiler/react-compiler, react-hooks/exhaustive-deps
	}, [isComposerFullSize]);

so when the when the composer was full size the scroll top had a smaller value (that is because the composer had greater height and needs to scroll with smaller value to show the bottom of the composer than when it is non-full size) so when we switch it to non-full size that small value of scrollTop will not be enough to show the bottom of the composer.

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

We need to set the scrollTop in such a way that the content on the bottom of the composer will be persitent on toggling isComposerFullSize so: we should add height state to hold previous clientHeight the change

App/src/components/Composer/index.tsx

Line 232 in 25450d9

setPrevScroll(textInput.current.scrollTop);

            setPrevScroll(textInput.current.scrollTop);
            setPrevHeight(textInput.current.clientHeight);

App/src/components/Composer/index.tsx

Lines 268 to 271 in 25450d9

	// eslint-disable-next-line react-compiler/react-compiler
	textInput.current.scrollTop = prevScroll;
	// eslint-disable-next-line react-compiler/react-compiler, react-hooks/exhaustive-deps
	}, [isComposerFullSize]);

 if (!textInput.current || prevScroll === undefined || prevHeight === undefined) {
            return;
        }
        // eslint-disable-next-line react-compiler/react-compiler
        textInput.current.scrollTop = prevScroll + prevHeight - textInput.current.clientHeight;
       

What alternative solutions did you explore? (Optional)

We if we want the center of the content persistent we can change

        textInput.current.scrollTop = prevScroll + prevHeight / 2 - textInput.current.clientHeight / 2 ;

[melvin-bot]

@anmurali Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!

[melvin-bot]

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

[melvin-bot]

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

[melvin-bot]

@anmurali, @rayane-djouah Eep! 4 days overdue now. Issues have feelings too...

[rayane-djouah]

Sorry for the delay! will review this one later today / tomorrow

[QichenZhu]

Proposal

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

Composer's caret scroll position is not maintained after resuming from expanded mode.

What is the root cause of that problem?

The line below maintains the scrollTop of the Composer, which means it maintains the scroll position of the first line in the visible area. If the distance between the first line and the caret is greater than the Composer height after resizing, the first line is still visible, but the caret is not.

App/src/components/Composer/index.tsx

Line 269 in 526845b

textInput.current.scrollTop = prevScroll;

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

In Chrome, if the caret is not visible, after typing a charector, the caret will be scrolled to the visible area. We can implement similar behavior by replacing the above line with the code below.

const selectionRect = window.getSelection()?.getRangeAt(0).getBoundingClientRect();
const textInputRect = textInput.current.getBoundingClientRect();

if (selectionRect && (selectionRect.top < textInputRect.top || selectionRect.bottom > textInputRect.bottom)) {
    textInput.current.scrollTop += selectionRect.top - textInputRect.top;
} else {
    // eslint-disable-next-line react-compiler/react-compiler
    textInput.current.scrollTop = prevScroll;
}

What alternative solutions did you explore? (Optional)

In Chrome, after you blur and focus the Composer, the caret will be scrolled into the visible area. We can emulate this behavior by inserting the code below after the line mentioned in the root cause.

const selectionRect = window.getSelection()?.getRangeAt(0).getBoundingClientRect();
const textInputRect = textInput.current.getBoundingClientRect();

if (selectionRect && (selectionRect.top < textInputRect.top || selectionRect.bottom > textInputRect.bottom)) {
    textInput.current.blur();
    textInput.current.focus();
}

[QichenZhu]

Could we clarify the expected behavior? Since some content has to be hidden after shrinking the Composer, what should be visible after resizing? The first line, the middle of the text, the last line, or the caret ▎?

Behavior	Expanded	Collapsed
The first line is visible (current behavior)	Line 1 Line 2 Line 3 Line 4 ▎ Line 5 Line 6 Line 7 Line 8 Line 9 Line 10 Line 11	Line 1 Line 2 Line 3
The middle of the text is visible	Line 1 Line 2 Line 3 Line 4 ▎ Line 5 Line 6 Line 7 Line 8 Line 9 Line 10 Line 11	Line 5 Line 6 Line 7
The last line is visible	Line 1 Line 2 Line 3 Line 4 ▎ Line 5 Line 6 Line 7 Line 8 Line 9 Line 10 Line 11	Line 9 Line 10 Line 11
The caret is visible (my proposal)	Line 1 Line 2 Line 3 Line 4 ▎ Line 5 Line 6 Line 7 Line 8 Line 9 Line 10 Line 11	Line 4 ▎ Line 5 Line 6

[melvin-bot]

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

[rayane-djouah]

Could we clarify the expected behavior? Since some content has to be hidden after shrinking the Composer, what should be visible after resizing? The first line, the middle of the text, the last line, or the caret ▎?

Good question! @Expensify/design Could you clarify the expected result? The video below demonstrates the current behavior, where we keep the first visible line in view when resizing the composer. In my opinion, we should scroll to the caret position instead. What do you think?

Screen.Recording.2024-10-02.at.5.16.35.PM.mov

[dannymcclain]

Hmm, what's shown in the video honestly doesn't feel weird to me. It kinda looks like we're "respecting" the scroll position that was already there. But I also think it could make sense to always show the cursor/caret. So I think personally I'd opt for one of those two options. Let's see what @dubielzyk-expensify thinks!

[FitseTLT]

In my opinion, we should scroll to the caret position instead.

@rayane-djouah If a user has scrolled up from where the cursor is located and switches the composer size I doubt if the user expects it to be scrolled to the caret position. What I think and based my proposal on was we should as much as possible make the visible content of the composer consistent across the two composer size states. Currently, we are making the top content consistent on toggling composer size that's why we facing the current issue. So we can make the bottom or middle of content consistent instead. @dannymcclain WDYT

[dubielzyk-expensify]

I actually think we should respect the scroll position over the caret here. Cause I think you'd expect the view to expand not for the view to shift and follow the caret. I vote scroll position 👍

[dannymcclain]

Ok thanks @dubielzyk-expensify! That makes me think that our current behavior is what we want (keep the first visible line in view when resizing). Do you agree?

[FitseTLT]

Ok thanks @dubielzyk-expensify! That makes me think that our current behavior is what we want (keep the first visible line in view when resizing). Do you agree?

The logic of the expected result in the OP is that switching to full-size and back to normal-size, they expected the content visible to be on the same scroll level it was before toggling to full-size. This happens in most cases but when the scroll level is the down-end, when the user changes to full-size, the top line when it was non-full sized will now be in the middle on full-size (obviously b/c full-size will accomodate more content) so when swiching back to non-full sized it will keep the first line in view so it will be in a scrolled-up state than it was originally, which kind of unexpected.

[dubielzyk-expensify]

Ahhh right. I see what you mean now. I guess because the text grows from bottom up it feels weird that we align the scroll position to the top of the compose bar. Okay I think I get it.

In that instance I guess I think we should make sure that it follows the bottom of the compose bar. So when you expand, the last line should stay the same. That way you never get into a weird thing where you're at the bottom of the compose bar, expand it, and you lose your position. Does that sound right?

[dannymcclain]

Yeah that sounds good to me! I guess for the composer the bottom is really the "anchor" so what you're suggesting makes sense.

[melvin-bot]

@anmurali @rayane-djouah this issue was created 2 weeks ago. Are we close to approving a proposal? If not, what's blocking us from getting this issue assigned? Don't hesitate to create a thread in #expensify-open-source to align faster in real time. Thanks!

[rayane-djouah]

Thanks for clarifying the expected result

[melvin-bot]

@anmurali, @rayane-djouah Whoops! This issue is 2 days overdue. Let's get this updated quick!

[rayane-djouah]

@FitseTLT's proposal looks good to me

🎀👀🎀 C+ reviewed

Screen.Recording.2024-10-07.at.11.27.39.PM.mov

[melvin-bot]

Triggered auto assignment to @marcaaron, see https://stackoverflow.com/c/expensify/questions/7972 for more details.

[melvin-bot]

📣 @rayane-djouah 🎉 An offer has been automatically sent to your Upwork account for the Reviewer role 🎉 Thanks for contributing to the Expensify app!

Offer link
Upwork job

[melvin-bot]

📣 @FitseTLT 🎉 An offer has been automatically sent to your Upwork account for the Contributor role 🎉 Thanks for contributing to the Expensify app!

Offer link
Upwork job
Please accept the offer and leave a comment on the Github issue letting us know when we can expect a PR to be ready for review 🧑‍💻
Keep in mind: Code of Conduct | Contributing 📖

[rayane-djouah]

PR under review