[$500] Chat - The composer jumps when editing a message

[m-natarajan]

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.4.40-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:

Action Performed:

1. Navigate to a chat with a lot of text messages
2. Edit the text closest to the composer

Expected Result:

It shouldn't shake or jump

Actual Result:

The composer jumps when editing a message - see this video for an example

Workaround:

unknown

Platforms:

Which of our officially supported platforms is this issue occurring on?

• [x] Android: Native
• [ ] Android: mWeb Chrome
• [x] iOS: Native
• [ ] iOS: mWeb Safari
• [ ] MacOS: Chrome / Safari
• [ ] MacOS: Desktop

Screenshots/Videos

Add any screenshot/video evidence

https://github.com/Expensify/App/assets/38435837/f101889f-6e39-46c6-9ceb-9bcea89cd234

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~011ebf704e63731d68
• Upwork Job ID: 1757147558004047872
• Last Price Increase: 2024-04-01

[melvin-bot[bot]]

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

[melvin-bot[bot]]

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

[melvin-bot[bot]]

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

[m-natarajan]

We (Applause) think this bug might be related to #vip-vsb

[jliexpensify]

@ntdiary I got assigned a similar action (i.e. shaking occurs when tapping on something) here: https://github.com/Expensify/App/issues/34300

Do you think the root cause would be the same?

[ntdiary]

@ntdiary I got assigned a similar action (i.e. shaking occurs when tapping on something) here: #34300

Do you think the root cause would be the same?

Hi, @jliexpensify, I'm still OOO. If this is a urgent issue, please feel free to reassign another c+, or maybe I'll have 1-2 hours to dig deeper tomorrow. :)

[melvin-bot[bot]]

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

[jliexpensify]

Than ks @ntdiary - going to reassign for now! @s77rt - please see my question here!

[s77rt]

@jliexpensify No they seem different. This one is related to the main composer getting hidden which makes the editing composer change position (jump)

[jliexpensify]

@m-natarajan you checked the ios: native box but your video seems to be iOS Safari (or another browser).

I also can't really reproduce this, @s77rt could this issue be related to how the keyboard pops up?

[s77rt]

@jliexpensify No, it's only due to the fact that we are hiding the main composer so everything shift down including the edit composer

https://github.com/Expensify/App/assets/16493223/52a8a3e2-8790-4a9a-abdc-6fa04bcdc79e

Before	After

[jliexpensify]

Thanks for sharing that video @s77rt - I can see it a bit more clearly now. Is it something that is a pretty simple/straightforward fix?

[s77rt]

@jliexpensify I didn't check in depth but I don't think fixing this would be straightforward.

[jliexpensify]

Cool, lets wait for some proposals then - thanks!

EDIT: posted here - https://expensify.slack.com/archives/C066HJM2CAZ/p1707880547642609

[s77rt]

Not overdue. Looking for proposals

[melvin-bot[bot]]

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

[jliexpensify]

Waiting for proposals!

[s77rt]

Still looking for proposals

[melvin-bot[bot]]

@s77rt @jliexpensify 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!

[melvin-bot[bot]]

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

[melvin-bot[bot]]

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

[s77rt]

Still looking for proposals

[s77rt]

Still looking for proposals

[s77rt]

Same ^

[melvin-bot[bot]]

@s77rt @jliexpensify this issue is now 3 weeks old. There is one more week left before this issue breaks WAQ and will need to go internal. What needs to happen to get a PR in review this week? Please create a thread in #expensify-open-source to discuss. Thanks!

[melvin-bot[bot]]

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

[jliexpensify]

@s77rt can you reproduce this one? I tried again and don't see the jump on Android. I wonder if this is just a mobile limitation with the keyboard pushing the edited sentence up and then down?

[s77rt]

@jliexpensify The jump behaviour is more noticeable on mWeb. Though this seems a minor bug, do you think we should close the issue?

[jliexpensify]

I think we should still keep it open, I'll post to the Open-Source channel since we haven't had any proposals yet!

[melvin-bot[bot]]

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

[melvin-bot[bot]]

@s77rt @jliexpensify this issue is now 4 weeks old and preventing us from maintaining WAQ, can you:

• Decide whether any proposals currently meet our guidelines and can be approved as-is today
• If no proposals meet that standard, please take this issue internal and treat it as one of your highest priorities
• If you have any questions, don't hesitate to start a discussion in #expensify-open-source

Thanks!

[melvin-bot[bot]]

Current assignee @s77rt is eligible for the Internal assigner, not assigning anyone new.

[s77rt]

Still looking for proposals. Should we make this External again?

[brunovjk]

Although I'm aware that there isn't an External + Help Wanted tag, I went ahead and drafted a proposal for the issue. I would appreciate any feedback.

[brunovjk]

Proposal

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

The problem is the unexpected jump in the composer when editing messages in a chat with numerous text messages.

What is the root cause of that problem?

I see two problems here:

1 - When rendering the ReportActionItemMessageEdit composer, we always start with two lines and then update the numberOfLines later.

The flicker that this issue causes is small (more noticeable when we have multiple lines) but I believe it is worth fixing.

2 - Today we also deal with ONYXKEYS.SHOULD_SHOW_COMPOSE_INPUT when editing message: https://github.com/Expensify/App/blob/4ac2dd7d391b53b5b8afc480cae61d8335da3209/src/pages/home/report/ReportActionItemMessageEdit.tsx#L428 and https://github.com/Expensify/App/blob/4ac2dd7d391b53b5b8afc480cae61d8335da3209/src/pages/home/report/ReportActionItemMessageEdit.tsx#L445 Generating a 'out of sync' behavior when rendering/hiding both edit and main composers, which leads to this 'flicking' feeling. Also the use of setShouldShowComposeInputKeyboardAware(true) on composer blur creates another issue, steps to reproduce:

1. Navigate to a chat with 2 text messages or more.
2. Start editing two messages, the main composer is hidden as it should be.

3. Press X to cancel editing one message, note that the main composer appears, but it should remain hidden, since we still have another edit composer opened.

   Main composer don't stay hidden

   https://github.com/Expensify/App/assets/95647348/94522d47-04d7-45ae-9ec8-a3e51cc49a59

The root cause is the dynamic hiding of the main composer when editing a message/comment:

https://github.com/Expensify/App/blob/4ac2dd7d391b53b5b8afc480cae61d8335da3209/src/pages/home/report/ReportFooter.tsx#L134 Leading to abrupt movements during message editing.

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

1. Implemented dynamic calculation of Composer component's number of lines based on draft content length. I couldn't put the videos side by side :p

   numberOfLines - 6 lines - Before

   https://github.com/Expensify/App/assets/95647348/2164eea0-8263-4e97-971c-46a8b30be315
   Dynamic numberOfLines - 6 lines - After

   https://github.com/Expensify/App/assets/95647348/2eb3819a-7948-4504-afef-03362889234f

   Here is a branch/commit that I used on the videos above. The idea is to pass the numberOfLines to the edit composer as props. However, the way I calculated the numberOfLines in ReportActionItemMessageEdit can/should be reviewed and confirmed that it is in accordance with Expensify best practices.

2. Still working on the solution, I believe we need to update how we handle draftMessage and setShouldShowComposeInputKeyboardAware in ReportActionItem and ReportActionItemMessageEdit respectively. Create animations/transitions conditional on these variations, Using import * as Animatable from 'react-native-animatable';. I'm working on it and will have a POC soon.

What alternative solutions did you explore? (Optional)

[s77rt]

@brunovjk Thanks for the proposal. Your RCA makes sense. Regarding the suggested solution I'm not sure if animation would help much here. Were you able to work on a PoC? As for the alternative solution we don't want to use the main composer because we want to have the ability to edit multiple messages at the same time.

[melvin-bot[bot]]

Current assignee @s77rt is eligible for the External assigner, not assigning anyone new.

[jliexpensify]

Made this one External, hopefully we get some more input!

[jeremy-croff]

@jliexpensify No, it's only due to the fact that we are hiding the main composer so everything shift down including the edit composer

Screen.Recording.2024-02-14.at.2.13.26.AM.mov Before After

In this video, would you want the keyboard to pop up?

[s77rt]

@jeremy-croff I don't want the keyboard to pop up. That was a demonstration that the location of the edit input changes.

[brunovjk]

Were you able to work on a PoC? As for the alternative solution we don't want to use ...

Working on it. Thank you for the feedback.

[brandonhenry]

Proposal

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

The composer jumps or shifts abruptly when a user starts editing a message in a chat with many messages. This creates a jarring user experience.

What is the root cause of that problem?

The root cause is that the main composer is abruptly hidden without any animation when the shouldShowComposeInput prop changes to false. This sudden hiding causes the chat area and the editing composer to jump upwards to fill the vacated space.

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

We should use the react-native-reanimated library to smoothly animate the main composer's visibility and height when the shouldShowComposeInput prop changes.

1. Add a new animated value mainComposerVisible that's initialized based on shouldShowComposeInput.

2. Create an animated style mainComposerStyle that animates the opacity and height of the main composer based on mainComposerVisible.

3. Use useSharedValue, useAnimatedStyle, and withTiming to define the animations.

4. Add a useEffect hook that animates mainComposerVisible when shouldShowComposeInput changes.

5. Use the measure method to get the actual height of the main composer and animate to that height.

6. Apply the mainComposerStyle to the main composer view.

Link to test PR

Note: in my PR, I created a RNView for an Animated View component, very similar to the RNTextInput that we have the Animated Text Input setup. This will be needed so we keep this change specific to native

Result

Before

https://github.com/Expensify/App/assets/15656774/2077b54a-c53c-41a9-8025-d528787d2cc2

After

https://github.com/Expensify/App/assets/15656774/f60f4669-113e-4eaf-800e-3565a9f3663a

What alternative solutions did you explore? (Optional)

• Conditionally rendering the main composer based on shouldShowComposeInput. However, this caused visual glitches and didn't allow for smooth animations.

• Using the Animated API directly on the style props. But using react-native-reanimated provides better performance and more flexibility for complex animations.

• Animating the height and opacity separately. But combining them into a single animated style resulted in cleaner and more synchronized animations.

[s77rt]

@brandonhenry Thanks for the proposal. Your RCA is correct. Regarding the solution can you please attach a before and after videos for comparison?

[brandonhenry]

@s77rt updated proposal

[s77rt]

@brandonhenry Thanks for the update. I'm not sure how is new behaviour better than what we have now. It kinda makes the app feel slower. cc @Expensify/design https://github.com/Expensify/App/issues/36374#issuecomment-1995705491

[brunovjk]

@s77rt I'm still working on this, and it looks like we have more problems:

1 - The first render of the ReportActionItemMessageEdit composer has 2 lines by default, and a moment later we calculate the number of lines correctly. I believe this is helping a little with the 'jumping' feeling, but it is not the main cause.

2 - When start and finish the edit, there are times with 2 composers rendered and times with 0 composers. I wonder if there is a way to render composers synchronously, with a smooth transition or something, still testing.

This video from the Performance tab shows it better:

https://github.com/Expensify/App/assets/95647348/155dd42b-8582-4e9a-875b-27032260d47d

3 - If you edit two separate messages, press X to cancel (blur) on one of them, the main composer appears.

I believe it's related to setShouldShowComposeInputKeyboardAware and ComposerActions.setShouldShowComposeInput in ReportActionItemMessageEdit and how we handle rendering/hide composers on ReportActionItem, but I am still working on solutions that do not cause regressions. I will be back as soon as I have it. Any help/feedback is welcome.

[dubielzyk-expensify]

I don't mind this solution at all. Yes there's a slight animation delay but it feels right to me and this isn't the most common action so I'm okay with it. Keen to hear what the other @Expensify/design thinks

[brandonhenry]

We can also adjust the delay so its not too "slow" @s77rt , the main thing is just having an animation in general. We can adjust speed in PR if this is route we're looking to go. Right now, code is purposefully using CONST.ANIMATED_TRANSITION (300ms)

[brunovjk]

Proposal

Updated

@s77rt I believe we have some questions/issue here:

1. When rendering the ReportActionItemMessageEdit composer, we always start with two lines and then update the numberOfLines later, generating a small flick, more noticeable in messages with multiple lines.
2. Nonexistent transition/animation in Rendering/hiding of edit composer and main composer, generating flicks and jumps. We can try to align these transitions with ONYXKEYS.SHOULD_SHOW_COMPOSE_INPUT
3. Main composer appears even when we still have an edit composer open. Steps to reproduce in the proposal.

[s77rt]

@brunovjk Thanks for the update. Good catch with the multiline issue. Can you please outline how we will fix that without PRs / code diffs?