[$500] Chat --Tapping expand button and then plus icon, the compose box becomes extra big

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

---

Action Performed:

1. Go to https://staging.new.expensify.com/
2. Tap on a report
3. Enter a number
4. Tap enter few times and enter other number
5. Tap plus icon near compose and close it by tapping on outside
6. Note the size of compose box
7. Tap expand button
8. Tap plus icon near compose and note background compose box become extra big
9. Tap outside and close plus icon options and note size of compose box

Expected Result:

When user taps expand button and taps plus icon near compose, the compose box must not become extra big

Actual Result:

When user taps expand button and taps plus icon near compose, the compose box becomes extra big

Workaround:

Unknown

Platforms:

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

• Android / native
• Android / Chrome
• iOS / native
• iOS / Safari
• MacOS / Chrome / Safari
• MacOS / Desktop

Version Number: 1.3.74-0

Reproducible in staging?: Yes

Reproducible in production?: Yes

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

Notes/Photos/Videos: Any additional supporting documentation

Bug6214224_box_big.mp4

Expensify/Expensify Issue URL:

Issue reported by: Applause - Internal Team

Slack conversation:

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~0170623ae497958496
• Upwork Job ID: 1706527705972113408
• Last Price Increase: 2023-10-10

[melvin-bot]

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

[melvin-bot]

Bug0 Triage Checklist (Main S/O)

• This "bug" occurs on a supported platform (ensure Platforms in OP are ✅)
• This bug is not a duplicate report (check E/App issues and #expensify-bugs)
  • If it is, comment with a link to the original report, close the issue and add any novel details to the original issue instead
• This bug is reproducible using the reproduction steps in the OP. S/O
  • If the reproduction steps are clear and you're unable to reproduce the bug, check with the reporter and QA first, then close the issue.
  • If the reproduction steps aren't clear and you determine the correct steps, please update the OP.
• This issue is filled out as thoroughly and clearly as possible
  • Pay special attention to the title, results, platforms where the bug occurs, and if the bug happens on staging/production.
• I have reviewed and subscribed to the linked Slack conversation to ensure Slack/Github stay in sync

[melvin-bot]

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

[melvin-bot]

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

[omergr8]

Subject: Tapping expand button and then plus icon, the compose box becomes extra big.

Issue Overview

Currently, when a user clicks on the "stretch" button, it applies the CSS property flex: 1 1 0%; to the textarea div (the second sibling). However, its sibling div, the chat div, already has the same flex: 1 1 0% property applied. This results in both sibling divs taking equal amounts of space, which leads to the issue where the chat textarea becomes larger when the keyboard disappears.

Proposed Solution

The proposed solution is to dynamically adjust the flex properties of the sibling divs when the textarea is expanded. Specifically, we can set the chat area to occupy 70% of the available space, while the text area takes up the remaining 30%. By doing so, we can ensure that the textarea's size remains consistent and does not unexpectedly change when the keyboard appears or disappears.

Implementation Details

To implement this solution, we can employ JavaScript to toggle the flex properties of the sibling divs upon clicking the "stretch" button. Here's a high-level overview of the steps:

1. When the "stretch" button is clicked:
   • Remove the inherited flex: 1 1 0%; property from both sibling divs.
   • Apply flex: 7 to the chat area div (occupying 70% of available space).
   • Apply flex: 3 to the text area div (occupying 30% of available space).

This adjustment ensures that the chat area remains larger, while the text area remains smaller, creating a more consistent user experience.

Expected Benefits

• Prevents the textarea from unexpectedly changing size when interacting with the keyboard.
• Enhances the user experience by maintaining a stable layout.
• Offers greater control over the distribution of space between the sibling divs within the flex container.

Additional Considerations

• Compatibility with various screen sizes and devices should be thoroughly tested to ensure responsiveness.
• Accessibility and user testing should be conducted to validate the proposed solution.

[melvin-bot]

📣 @omergr8! 📣
Hey, it seems we don’t have your contributor details yet! You'll only have to do this once, and this is how we'll hire you on Upwork.
Please follow these steps:

1. Make sure you've read and understood the contributing guidelines.
2. Get the email address used to login to your Expensify account. If you don't already have an Expensify account, create one here. If you have multiple accounts (e.g. one for testing), please use your main account email.
3. Get the link to your Upwork profile. It's necessary because we only pay via Upwork. You can access it by logging in, and then clicking on your name. It'll look like this. If you don't already have an account, sign up for one here.
4. Copy the format below and paste it in a comment on this issue. Replace the placeholder text with your actual details.
   
   Format:

Contributor details
Your Expensify account email: <REPLACE EMAIL HERE>
Upwork Profile Link: <REPLACE LINK HERE>

[omergr8]

Contributor details
Your Expensify account email: umar.mukhtar4455@gmail.com
Upwork Profile Link: https://www.upwork.com/freelancers/~01c0eeade85c091525

[melvin-bot]

✅ Contributor details stored successfully. Thank you for contributing to Expensify!

[suneox]

Proposal

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

Chat --Tapping expand button and then plus icon, the compose box becomes extra big

What is the root cause of that problem?

When the input is set to full size the height of the footer input group will get 50% remaining height (exclude header) at

App/src/pages/home/report/ReportFooter.js

Line 80 in 13b2291

<View style={[chatFooterStyles, props.isComposerFullSize && styles.chatFooterFullCompose]}>

by styles.chatFooterFullCompose flex: 1

on mobile when the keyboard opens the height of the input group will reduce due to the total height being reduced

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

Condition to check isMobile

  const isMobile = Browser.isMobile() || Platform.OS === 'ios' || Platform.OS === 'android';

On mobile the height of the screen is limited with the keyboard so we shouldn't support to expand full composer, we will hide the expand and collapse buttons at

App/src/pages/home/report/ReportActionCompose/AttachmentPickerWithMenuItems.js

Line 200 in 13b2291

{isComposerFullSize && (

update to

  {!isMobile && isComposerFullSize && (
    ....
  )}

and

App/src/pages/home/report/ReportActionCompose/AttachmentPickerWithMenuItems.js

Line 219 in 13b2291

{!isComposerFullSize && isFullComposerAvailable && (

update to

  {!isMobile && !isComposerFullSize && isFullComposerAvailable && (
    ....
  )}

Make an attachment button to center

App/src/pages/home/report/ReportActionCompose/AttachmentPickerWithMenuItems.js

Line 199 in 13b2291

<View style={[styles.dFlex, styles.flexColumn, isFullComposerAvailable || isComposerFullSize ? styles.justifyContentBetween : styles.justifyContentCenter]}>

update to

  <View style={[styles.dFlex, styles.flexColumn, !isMobile && isFullComposerAvailable || !isMobile && isComposerFullSize ? styles.justifyContentBetween : styles.justifyContentCenter]}>

Result on mobile

What alternative solutions did you explore? (Optional)

We can config a height or maxHeight for the input group on mobile instead of setting flex:1

App/src/pages/home/report/ReportFooter.js

Line 80 in 13b2291

<View style={[chatFooterStyles, props.isComposerFullSize && styles.chatFooterFullCompose]}>

  <View style={[chatFooterStyles, props.isComposerFullSize ? (isMobile ? styles.chatFooterFullComposeMobile : styles.chatFooterFullCompose) : undefined]}>

add style chatFooterFullComposeMobile bellow chatFooterFullCompose

    chatFooterFullComposeMobile: {
        height: 180, // 180-(7 lines) 200-(8 lines) or calculate any value based on team decision
    },

Result on mobile

[greg-schroeder]

awaiting proposal review

[hoangzinh]

@omergr8 please follow our proposal template here https://github.com/Expensify/App/blob/main/contributingGuides/PROPOSAL_TEMPLATE.md

[hoangzinh]

@greg-schroeder I traced back changelogs, we used to expand composer to full-screen last year #9031 #11608. But nowadays, It only occupies 50% of the screen height when the keyboard is hidden.

I couldn't find when we changed from 100% to 50% screen in expand mode.

So just wanna confirm the expected behavior here, in expand mode, will the composer occupy 100% or 50% or any percentage of screen height (or fixed height)? Thanks

[omergr8]

Proposal

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

Tapping expand button and then plus icon, the compose box becomes extra big.

What is the root cause of that problem?

The root cause of this problem is the conflicting flex properties applied to both sibling divs. This conflict causes them to share space equally, leading to the unintended resizing of the chat textarea.

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

To address this issue, I propose dynamically adjusting the flex properties of the sibling divs when the textarea is expanded. Specifically, I suggest setting the chat area to occupy 70% of the available space, while the text area takes up the remaining 30%. This adjustment will ensure that the textarea's size remains consistent and does not unexpectedly change when the keyboard appears or disappears.

What alternative solutions did you explore?

In addition to the proposed solution that involves adjusting the flex properties of the sibling divs, we explored an alternative approach. Instead of relying on flex, an alternative solution would involve setting a fixed height or a maximum height (max-height) for the input group. This alternative approach simplifies the layout management by avoiding complex flex adjustments and may offer an effective way to address the issue.

[suneox]

I have updated the screenshot result for my proposal @hoangzinh @greg-schroeder Could you please review my proposal?

[hoangzinh]

Thanks @suneox . I would like to wait for @greg-schroeder for the expectation here #28201 (comment)

[greg-schroeder]

Looking

[greg-schroeder]

@hoangzinh hmm. I see conflicting information about this as well. 🤔

[greg-schroeder]

pinging here to see if anyone can be a better sleuth: https://expensify.slack.com/archives/C01GTK53T8Q/p1696260318348419

[greg-schroeder]

from @puneetlath:

it’s supposed to expand to the size where there is still space for the auto-complete menu, aka the menu that shows if you type @ or :

[melvin-bot]

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

[hoangzinh]

@greg-schroeder actually, I think we're still fine with the current size of the composer when it's expanded. The compose box in the recording is not extra big, it's the current size of the composer when the keyboard is hidden. What do you think?

[omergr8]

@hoangzinh
I believe it appears unattractive. Having a textarea with that height isn't aesthetically pleasing.

[hoangzinh]

@hoangzinh I believe it appears unattractive. Having a textarea with that height isn't aesthetically pleasing.

Because the composer is in the expand mode. Having extra space is expected behavior.

Current Expand mode with keyboard	Current Expand mode without keyboard

I just wanna confirm it's worth to fix this issue

[melvin-bot]

@hoangzinh, @greg-schroeder Huh... This is 4 days overdue. Who can take care of this?

[melvin-bot]

@hoangzinh @greg-schroeder 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!

[hoangzinh]

waiting on your input @greg-schroeder #28201 (comment)

[melvin-bot]

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

[greg-schroeder]

Sorry @hoangzinh been traveling/OOO

[greg-schroeder]

Hmm. The fact that it's the same size as when the keyboard is hidden is compelling enough to me to say this isn't worth spending our focus on.