[HOLD for payment 2023-08-07] [$1000] mWeb- Image is displayed larger then normal when we send vertical image with text on android chrome

[kbecciv]

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. Open the app
2. Open any report
3. Send any normal message
4. Type any normal message and click on plus
5. Click on add attachment
6. Select any vertical image and click on send
7. Observe that image is displayed larger then normal, to compare, send same image again normally without any text

Expected Result:

App should display image in normal size if we send the image along with text

Actual Result:

App displays image larger then normal if we send vertical image along with text

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.37-2
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
Notes/Photos/Videos: Any additional supporting documentation

larger.then.normal.image.sent.with.text.android.chrome.mp4

Screen_Recording_20230706_143639_Chrome.mp4

Expensify/Expensify Issue URL:
Issue reported by: @dhanashree-sawant
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1688634116891079

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~01d1b35099ea0fe207
• Upwork Job ID: 1678791252929392640
2023-07-18
• Automatic offers:
• | | 0
• ginsuma | Contributor | 25679036
• dhanashree-sawant | Reporter | 25679037

[melvin-bot]

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

[sakluger]

Good find, we should fix this.

[melvin-bot]

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

[melvin-bot]

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

[melvin-bot]

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

[ginsuma]

Proposal

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

mWeb- Image is displayed larger then normal when we send vertical image with text on android chrome.

What is the root cause of that problem?

We use window height for calculate the height of thumbnail.

App/src/components/ThumbnailImage.js

Line 65 in 3257e3e

let thumbnailScreenHeight = lodashClamp(imageHeight, 40, this.props.windowHeight * 0.4);

But when keyboard shows, window height is smaller than normal.
=> The thumbnail will show differently.
This issue only happen on iOS Safari and Android Chrome. On native apps, window height and screen height is same whether keyboard shows or not.

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

When we use a device with DeviceCapabilities.canUseTouchScreen(), we will use screen height instead of window height for calculation.

const upperHeight = DeviceCapabilities.canUseTouchScreen() ?  Dimensions.get('screen').height : this.props.windowHeight;
let thumbnailScreenHeight = lodashClamp(imageHeight, 40, upperHeight * 0.4);

We can modify 0.4 if needed too.

[sarious]

Proposal

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

Image is displayed larger then normal when we send vertical image with text on android chrome

What is the root cause of that problem?

The root of the problem is that this.props.windowHeight returns window height that calculated on each dimension change. But in moment of attaching document the Virtual Keyboard is shown, and this.props.windowHeight return the value that equal to windowSize minus keyboardSize. So the calculations of thumbnailScreenHeight is incorrect.

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

To fix the problem, we need to get window height without Virtual Keyboard. It will be real height of App view and it fix calculations of thumbnailScreenHeight, because the result will be consistant across same imageHeight and will be not depend on visibility of Virtual Keyboard.

So, to get initial window height without Virtual Keyboard we can invoke Dimensions.get('window') outside the class component. If we invoke it inside method or constructor it returns incorrect height (without Virtual Keyboard height)

And use it instead of this.props.windowHeight:

What alternative solutions did you explore? (Optional)

N/A

[rushatgabhane]

reviewing today

[sakluger]

@rushatgabhane were you able to review yet? If not, could you please prioritize this one?

[melvin-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]

@sakluger @rushatgabhane 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!

[sakluger]

Posted in #contributor-plus to make sure we can prioritize reviewing this issue.

[rushatgabhane]

@sarious your proposal won't work when the window is resized on web
your root cause is correct tho

[ginsuma]

Could I have a comment about my proposal #22363 (comment)?
Friendly ping @rushatgabhane .

[melvin-bot]

📣 @dhanashree-sawant 🎉 An offer has been automatically sent to your Upwork account for the Reporter role 🎉 Thanks for contributing to the Expensify app!

Upwork job

[sarious]

@sarious your proposal won't work when the window is resized on web your root cause is correct tho

I see. We can improve my proposal, and use dimensions.height only if canUseTouchScreen returns true:

const windowHeight = DeviceCapabilities.canUseTouchScreen() ? dimensions.height : this.props.windowHeight;

It looks similar to @ginsuma's proposal, but it seems that it's better to use window height. In @ginsuma proposal height of screen was used. But Window Height not equal to Screen Height, so the thumbnail height will be differ from initial (before fix).
Just wanted you know about this problem. If you are ok with that, you can continue with @ginsuma proposal.

[ginsuma]

#23392 is ready for review.
cc: @rushatgabhane @AndrewGable

But Window Height not equal to Screen Height

On mWeb it's right. I know it that's why I said we could edit 0.4 if needed in my proposal.
But the window resize problem is still there.

[melvin-bot]

Based on my calculations, the pull request did not get merged within 3 working days of assignment. Please, check out my computations here:

• when @ginsuma got assigned: 2023-07-21 17:07:09 Z
• when the PR got merged: 2023-07-27 21:10:50 UTC
• days elapsed: 4

On to the next one 🚀

[melvin-bot]

Reviewing label has been removed, please complete the "BugZero Checklist".

[melvin-bot]

The solution for this issue has been 🚀 deployed to production 🚀 in version 1.3.47-6 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:

• Fix ThumbnailImage on mWeb #23392

If no regressions arise, payment will be issued on 2023-08-07. 🎊

After the hold period is over and BZ checklist items are completed, please complete any of the applicable payments for this issue, and check them off once done.

• External issue reporter
• Contributor that fixed the issue
• Contributor+ that helped on the issue and/or PR

For reference, here are some details about the assignees on this issue:

• @ginsuma requires payment offer (Contributor)
• @rushatgabhane does not require payment (Eligable for Manual Requests)

As a reminder, here are the bonuses/penalties that should be applied for any External issue:

• Merged PR within 3 business days of assignment - 50% bonus
• Merged PR more than 9 business days after assignment - 50% penalty

[melvin-bot]

BugZero Checklist: The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed:

• [@rushatgabhane] The PR that introduced the bug has been identified. Link to the PR:
• [@rushatgabhane] The offending PR has been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake. Link to comment:
• [@rushatgabhane] A discussion in #expensify-bugs has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner. Link to discussion:
• [@rushatgabhane] Determine if we should create a regression test for this bug.
• [@rushatgabhane] If we decide to create a regression test for the bug, please propose the regression test steps to ensure the same bug will not reach production again.
• [@sakluger] Link the GH issue for creating/updating the regression test once above steps have been agreed upon:

[rushatgabhane]

1. The PR that introduced the bug has been identified. Link to the PR: Not a regression. This bug was present since the inception of time :)

2. The offending PR has been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake. Link to comment: N.A.

3. A discussion in #expensify-bugs has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner. Link to discussion: No

4. Determine if we should create a regression test for this bug. I'm not sure if it's worth it.

5. If we decide to create a regression test for the bug, please propose the regression test steps to ensure the same bug will not reach production again

   1. Open the app
   2. Open any report
   3. Send any normal message
   4. Type any normal message and click on plus
   5. Click on add attachment
   6. Select any vertical image and click on send
   7. Verify that image is same size as image without any text

[rushatgabhane]

Created a manual request - https://staging.new.expensify.com/r/530127434800510

[sakluger]

Summarizing payouts for this issue:

Bug reporter: @dhanashree-sawant $250 (hired and paid on Upwork)
Contributor: @ginsuma $1000 (hired on Upwork)
Contributor+: @rushatgabhane $1000 (payable via Manual Request after BZ checklist is completed)

Upwork job: https://www.upwork.com/jobs/~01d1b35099ea0fe207

[sakluger]

Paid everyone through Upwork, @JmillsExpensify and @anmurali passing the issue to you for C+ payment to Rushat via manual request.

[rushatgabhane]

@sakluger you can close this issue because the payment will be tracked on new dot

[sakluger]

I believe that we need to wait until @JmillsExpensify or @anmurali comments that the payment is approved before we can close out the issue.

@rushatgabhane let me know if I missed an announcement, but I think that's still the current process.

[JmillsExpensify]

Reviewed the details for @rushatgabhane. This is approved for payment on NewDot.

[sakluger]

Thanks! We're all set here.

[melvin-bot]

⚠️ Looks like this issue was linked to a Deploy Blocker here

If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.

If a regression has occurred and you are the assigned CM follow the instructions here.

If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future.