[Due for payment 2025-05-28] [$250] Reports > Trips empty state illustration is too large

[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: 9.1.32-7
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: @shawnborton
Slack conversation (hyperlinked to channel name): #Expensify Bugs

Action Performed:

1. Login with a new account
2. Click Reports > Trips
3. Observe the empty state illustration

Expected Result:

Trips empty state illustration 190x172 per here.

Actual Result:

Trips empty state illustration is too large

Workaround:

Unknown

Platforms:

Select the officially supported platforms where the issue was reproduced:

• Android: App
• Android: mWeb Chrome
• iOS: App
• iOS: mWeb Safari
• iOS: mWeb Chrome
• Windows: Chrome
• MacOS: Chrome / Safari
• MacOS: Desktop

Platforms Tested:

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

• Android: App
• Android: mWeb Chrome
• iOS: App
• iOS: mWeb Safari
• iOS: mWeb Chrome
• Windows: Chrome
• MacOS: Chrome / Safari
• MacOS: Desktop

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/~021919656711365978359
• Upwork Job ID: 1919656711365978359
• Last Price Increase: 2025-05-06

Issue Owner

Current Issue Owner: @trjExpensify

[melvin-bot]

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

[Shahidullah-Muffakir]

🚨 Edited by proposal-police: This proposal was edited at 2025-04-28 14:54:18 UTC.

Proposal

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

Trips empty state illustration is too large

What is the root cause of that problem?

1. min width of 400 is used here:
   

   App/src/pages/Search/EmptySearchView.tsx

   Line 128 in e7658a6

   lottieWebViewStyles: {backgroundColor: theme.travelBG, ...styles.emptyStateFolderWebStyles},

2. and width of 100% is applied, the width of the parent section is 400px, which will use the same 400px for the illustration as well.
   

   App/src/styles/index.ts

   Lines 5544 to 5545 in e7658a6

   	...sizing.w100,
   	minWidth: 400,

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

1. Update the min-width as per the new design requirements
2. and remove the width:100%

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

NA

[trjExpensify]

@Expensify/design can we get the spec we expect here, so I can update the OP?

[nabi-ebrahimi]

🚨 Edited by proposal-police: This proposal was edited at 2025-05-08 05:56:45 UTC.

Proposal

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

The Trips empty state illustration in Reports > Trips appears too large.

What is the root cause of that problem?

There are two problems here

1. We're setting min-width: 400 and width: '100%' in emptyStateFolderWebStyles, but no height is defined. As a result, the Lottie animation appears too large and doesn't maintain the intended dimensions.

2. The Lottie container width is smaller than the parent width, which is max-width: 400, so it shows like a square view without a top border radius.

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

1. Set the height of the Lottie webStyle to '100%' to ensure it scales proportionally and renders as intended. This will correctly scale the Lottie animation within its container while preserving its aspect ratio. You can find the relevant code here.

        lottieWebViewStyles: {backgroundColor: theme.travelBG, ...styles.emptyStateFolderWebStyles, ...styles.h100},
             

2.We should use fixed width and height values for small screens, as they work well. For larger screens, setting the container's width and height to '100%' ensures the height scales with the container's width. This prevents oversized Lotties and ensures the top border radius is applied correctly — it doesn't render as a square. here

      headerContentStyles: [
                        isSmallScreen ? StyleUtils.getWidthAndHeightStyle(375, 240) : StyleUtils.getWidthAndHeightStyle('100%', '100%'),
                        StyleUtils.getBackgroundColorStyle(theme.travelBG),
                    ],

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

N/A

What alternative solutions did you explore? (Optional)

[nyomanjyotisa]

🚨 Edited by proposal-police: This proposal was edited at 2025-04-28 15:10:59 UTC.

Proposal

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

Trips empty state illustration is too large

What is the root cause of that problem?

We use styles.emptyStateFolderWebStyles here, which set the minWidth to 400 and we don't set the height and it automatically follow the aspect ratio

App/src/pages/Search/EmptySearchView.tsx

Line 128 in e7658a6

lottieWebViewStyles: {backgroundColor: theme.travelBG, ...styles.emptyStateFolderWebStyles},

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

explicitly set the height or maxHeight to 240 or 220 or any other value to match the design doc

lottieWebViewStyles: {backgroundColor: theme.travelBG, ...styles.emptyStateFolderWebStyles, height: 240},

or

lottieWebViewStyles: {backgroundColor: theme.travelBG, ...StyleUtils.getWidthAndHeightStyle(400, 240)},

or

lottieWebViewStyles: {backgroundColor: theme.travelBG, ...styles.emptyStateFolderWebStyles, ...styles.staticHeaderImage},

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

None

What alternative solutions did you explore? (Optional)

add sizing.h100 to the styling to make the height 100% of the container height

lottieWebViewStyles: {backgroundColor: theme.travelBG, ...styles.emptyStateFolderWebStyles, ...sizing.h100},

or here

        emptyStateFolderWebStyles: {
            ...
            ...sizing.h100,
            ...
        },

[shawnborton]

Is there any way we can track down the regression? If we find out when/how this changed, we'll have the exact value that it used to be when it was implemented correctly.

[Shahidullah-Muffakir]

After looking into more, it seems previously the StyleUtils.getWidthAndHeightStyle(variables.w191, variables.h172) was used but later during some other PR it was updated to the new StyleUtils.getWidthAndHeightStyle(375, 240) :

App/src/pages/Search/EmptySearchView.tsx

Line 124 in cd58d89

headerContentStyles: [StyleUtils.getWidthAndHeightStyle(375, 240), StyleUtils.getBackgroundColorStyle(theme.travelBG)],

we can update it to the original width and height

[shawnborton]

Awesome, can you point me to the PR where it changed?

[nyomanjyotisa]

Seems like caused by this PR #53199

[trjExpensify]

Hm, that PR @nyomanjyotisa didn't change the width and height variables it doesn't look like, right?

This earlier commit changed the width variable from 335 to 375: 000807c in this PR: #48060

it seems previously the StyleUtils.getWidthAndHeightStyle(variables.w191, variables.h172) was used

I can't see those variables in the blame, myself.

[Shahidullah-Muffakir]

here is the PR
#48040