[Due for payment 2025-02-19] [$250] Android - Expense - Tapping Create expense button, category and description field greyed out.

[vincdargento]

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: V9.0.89-0
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught on HybridApp, is this reproducible on New Expensify Standalone?: Yes, reproducible on both
If this was caught during regression testing, add the test name, ID and link from TestRail: N/A
Email or phone of affected tester (no customers): N/A
Issue reported by: Applause Internal Team
Device used: Redmi note 10s android 13
App Component: Money Requests

Action Performed:

1. Launch app
2. Open a workspace chat
3. Start creating a split scan expense
4. In the confirmation page, tap split expense and note category and description field
5. Start creating a scan expense
6. In the confirmation page, tap create expense and note category and description field

Expected Result:

Tapping create expense button, category and description field must not be greyed out or both fields should be greyed out for split expense flow also.

Actual Result:

While creating split scan expense, tapping split expense doesn't greys out category and description field but for scan expense it is greyed out.

Workaround:

Unknown

Platforms:

• Android: Standalone
• Android: HybridApp
• Android: mWeb Chrome
• iOS: Standalone
• iOS: HybridApp
• iOS: mWeb Safari
• MacOS: Chrome / Safari
• MacOS: Desktop

Screenshots/Videos

bug.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021884643951618066001
• Upwork Job ID: 1884643951618066001
• Last Price Increase: 2025-01-29
• Automatic offers:
• FitseTLT | Contributor | 105993432

Issue Owner

Current Issue Owner: @CortneyOfstad

[melvin-bot]

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

[FitseTLT]

🚨 Edited by proposal-police: This proposal was edited at 2025-01-24 18:52:43 UTC.

Proposal

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

Android - Expense - Tapping Create expense button, category and description field greyed out.

What is the root cause of that problem?

We set isConfirmed to true in createTransaction

App/src/pages/iou/request/step/IOURequestStepConfirmation.tsx

Lines 412 to 414 in fc199fa

	const createTransaction = useCallback(
	(selectedParticipants: Participant[], locationPermissionGranted = false) => {
	setIsConfirmed(true);

and we disable the menu items when the user has confirmed on the transaction creation

App/src/components/MoneyRequestConfirmationListFooter.tsx

Line 480 in fc199fa

disabled={didConfirm}

this is to disallow the pressing of the menu items after the user has confirmed until the modal is dismissed but as shouldGreyOutWhenDisabled is true by default the menu will appear greyed out when the navigation is slow like in Android case.

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

To show loading on the confirm button once it is confirmed we should pass isConfirmed to the isLoading prop for both type of buttons here

App/src/components/MoneyRequestConfirmationList.tsx

Lines 942 to 971 in f60c647

	const button = shouldShowSettlementButton ? (
	<SettlementButton
	pressOnEnter
	onPress={confirm}
	enablePaymentsRoute={ROUTES.IOU_SEND_ENABLE_PAYMENTS}
	addBankAccountRoute={bankAccountRoute}
	shouldShowPersonalBankAccountOption
	currency={iouCurrencyCode}
	policyID={policyID}
	buttonSize={CONST.DROPDOWN_BUTTON_SIZE.LARGE}
	kycWallAnchorAlignment={{
	horizontal: CONST.MODAL.ANCHOR_ORIGIN_HORIZONTAL.LEFT,
	vertical: CONST.MODAL.ANCHOR_ORIGIN_VERTICAL.BOTTOM,
	}}
	paymentMethodDropdownAnchorAlignment={{
	horizontal: CONST.MODAL.ANCHOR_ORIGIN_HORIZONTAL.RIGHT,
	vertical: CONST.MODAL.ANCHOR_ORIGIN_VERTICAL.BOTTOM,
	}}
	enterKeyEventListenerPriority={1}
	useKeyboardShortcuts
	/>
	) : (
	<ButtonWithDropdownMenu
	pressOnEnter
	onPress={(event, value) => confirm(value as PaymentMethodType)}
	options={splitOrRequestOptions}
	buttonSize={CONST.DROPDOWN_BUTTON_SIZE.LARGE}
	enterKeyEventListenerPriority={1}
	useKeyboardShortcuts
	/>

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

N/A : UI bug

What alternative solutions did you explore? (Optional)

[shubham1206agra]

🚨 Edited by proposal-police: This proposal was edited at 2025-01-25 18:28:40 UTC.

Proposal

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

Android - Expense - Tapping Create expense button, category and description field greyed out.

What is the root cause of that problem?

When we start creating the expense, we set isConfirmed to true in createTransaction function

App/src/pages/iou/request/step/IOURequestStepConfirmation.tsx

Line 414 in fc199fa

setIsConfirmed(true);

Also, we apply disabled property on the menu items when the didConfirm is true, which is being set using effect

Example of disabled prop-

App/src/components/MoneyRequestConfirmationListFooter.tsx

Line 480 in fc199fa

disabled={didConfirm}

Effect usage-

App/src/components/MoneyRequestConfirmationList.tsx

Lines 477 to 479 in b59f23b

	useEffect(() => {
	setDidConfirm(isConfirmed);
	}, [isConfirmed]);

Now, didConfirm will be true when we start creating the expense, since we set isConfirmed to true in createTransaction function.

Since we use the default properties related to disabled, when didConfirm is true, the menu items will grey out.

Note

The disabled property was added to prevent navigation to edit properties after starting the flow of creating an expense.

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

Instead of using disabled here, we can modify the interactive property of menu item as this will prevent us to use extra props to achieve the same behavior as non-interactive menu item, and it is more suitable to make the menu items non-interactive rather than disabled.

Example of modified interactive prop - interactive={!isReadOnly && !didConfirm}

And we would remove disabled prop completely.

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

NA since this is an UI bug

What alternative solutions did you explore? (Optional)

[melvin-bot]

@CortneyOfstad 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/~021884643951618066001

[melvin-bot]

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

[CortneyOfstad]

Hey @eh2077! We have a few proposals above for review when you have a chance. Thank you!

[eh2077]

Thanks for your proposals!

@shubham1206agra Though both properties, disabled and interactive, make onPressAction return early, they seem to have a nuanced impact on hovering and text selection. To avoid breaking other UI features, I would prefer to opt in the shouldGreyOutWhenDisabled property. Let me know if you have any other thoughts. Thanks!

[shubham1206agra]

Thanks for your proposals!

@shubham1206agra Though both properties, disabled and interactive, make onPressAction return early, they seem to have a nuanced impact on hovering and text selection. To avoid breaking other UI features, I would prefer to opt in the shouldGreyOutWhenDisabled property. Let me know if you have any other thoughts. Thanks!

@eh2077 The problem with keeping disabled will be problematic since we are aiming for non-interactive menu item, not the disabled menu item. Next problem you will see which you also need to suppress is that mouse pointer showing disabled when hovering over the items, which is again need to be suppressed via props.

See the difference in the video.

Disabled -

Screen.Recording.2025-01-30.at.9.20.20.PM.mov

Non-interactive -

Screen.Recording.2025-01-30.at.9.20.41.PM.mov

So, my recommendation is to use interactive prop rather than extra props to mimic the same behavior.

[FitseTLT]

Next problem you will see which you also need to suppress is that mouse pointer showing disabled when hovering over the items, which is again need to be suppressed via props.

I think the user would expect the menu to be disabled and the pointer showing that is correct, no need to avoid it with another prop. Non-interactive menu is not technically correct @eh2077 that's why they didn't use it for didConfirm non-interactive means we use it to display not to be clicked but here what we are doing is: it was an interactive/clickable menu but after the user confirmed on the expense creation flow it would be disabled on the transition of dismissing the modal. I think we should follow the original implementation of didConfirm using disabled and only remove the greying out. BTW I only attempted to solve the problem following the original implementation of using the disabled prop because it is the correct approach in principle to disabled it. 👍

[shubham1206agra]

it was an interactive/clickable menu but after the user confirmed on the expense creation flow it would be disabled on the transition of dismissing the modal.

@FitseTLT You are wrong here: We just don't want to users to accidentally click on menu item after starting to create an expense to avoid weird navigation bugs. That's why we have this bug marked. If the original intention is to show disabled menu item, then this issue would not have raised in the first place.

[FitseTLT]

it was an interactive/clickable menu but after the user confirmed on the expense creation flow it would be disabled on the transition of dismissing the modal.

@FitseTLT You are wrong here: We just don't want to users to accidentally click on menu item after starting to create an expense to avoid weird navigation bugs. That's why we have this bug marked. If the original intention is to show disabled menu item, then this issue would not have raised in the first place.

We implemented it to avoid accidental navigation on confirmation of the flow in the first place but we don't want that to affect the UI that is what we are dealing with in this issue. The prop shouldGreyOutWhenDisabled is there because there are cases where we don't want to grey out disabled menu and this is the perfect case to utilize it because we should disable the menu on confirmation not make it non-interactive we use interactive prop in conjunction with the right icon

App/src/components/MoneyRequestConfirmationListFooter.tsx

Lines 617 to 618 in 6118a1f

	shouldShowRightIcon={!isReadOnly}
	title={getSubratesForDisplay(field, translate('iou.qty'))}

App/src/components/MoneyRequestConfirmationListFooter.tsx

Lines 629 to 630 in 6118a1f

	interactive={!isReadOnly}
	brickRoadIndicator={index === 0 && shouldDisplaySubrateError ? CONST.BRICK_ROAD_INDICATOR_STATUS.ERROR : undefined}

to use the menu for display purpose and not clickable. But here it was interactive and after we confirm the end of the process we disable it that is the correct way in principle.

[eh2077]

Thank you for you comments!

Yeah, I agree that both disabled and interactive make onPressAction return early but they seem to have a nuanced impact on hovering and text selection. To avoid breaking other UI features, I would prefer to opt in the shouldGreyOutWhenDisabled property.

That said, I think we should go with @FitseTLT 's proposal.

🎀👀🎀 C+ reviewed

[melvin-bot]

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

[shubham1206agra]

To avoid breaking other UI features, I would prefer to opt in the shouldGreyOutWhenDisabled property.

@eh2077 Which UI features will be broken here if we opt for different approach?

[eh2077]

@shubham1206agra For example, from your comment #55728 (comment), I think the first clip is expected

• the menu item should be still interactive (Note there's a right arrow icon)
• and therefore the the pointer is not-allowed

See below screenshot

You can also look into https://github.com/Expensify/App/blob/main/src/components/MenuItem.tsx for nuanced differences between disabled and interactive.

[shubham1206agra]

I am sorry. But I am lost here since if we are expected to have disabled menu, then why should we not grey out the fields.

@Expensify/design Can you help us resolve this dispute since on one hand we are saying we should disable the field here (not make the field non-interactive), and on another hand we are saying we have a problem with grey out fields (which is a visual indicator of disabled fields)?

[trjExpensify]

Is this an Android-only bug or something? I can't repro on desktop/web.

[FitseTLT]

on another hand we are saying we have a problem with grey out fields (which is a visual indicator of disabled fields)

I don't see any conflict there. There are a lot of places in our code which we don't grey out disabled fields utilizing shouldGreyOutWhenDisabled prop which is there for this purpose like here

App/src/components/ReportActionItem/TaskView.tsx

Lines 139 to 141 in 4459f86

	disabled={disableState}
	wrapperStyle={[styles.pv2, styles.taskDescriptionMenuItem]}
	shouldGreyOutWhenDisabled={false}

We don't need to grey out the menu here because we don't expect the user to intentionally press the menu because they have confirmed but if they unintentionally hover it will show a disabled pointer.

[FitseTLT]

Is this an Android-only bug or something? I can't repro on desktop/web.

Yep you can only reproduce it on slower platforms @trjExpensify

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

[eh2077]

@FitseTLT Can you let us know when we can expect a PR for testing? Thanks!

[FitseTLT]

PR will be ready tomorrow

[melvin-bot]

@arosiclair @CortneyOfstad @FitseTLT @eh2077 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!

[eh2077]

We're waiting for the PR for testing.

[CortneyOfstad]

PR is close! Should be launched to staging soon! 🎉

[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 9.0.97-1 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:

• Fix - show loading on submit button after expense creation confirmed #56540

If no regressions arise, payment will be issued on 2025-02-19. 🎊

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

• @FitseTLT requires payment automatic offer (Contributor)
• @eh2077 requires payment through NewDot Manual Requests

[melvin-bot]

@eh2077 @CortneyOfstad @eh2077 The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed. Please copy/paste the BugZero Checklist from here into a new comment on this GH and complete it. If you have the K2 extension, you can simply click: [this button]

[CortneyOfstad]

@eh2077 — can you please complete the check list? Thanks!

[eh2077]

BugZero Checklist:

• [Contributor] Classify the bug:

Bug classification

Source of bug:

• 1a. Result of the original design (eg. a case wasn't considered)
• 1b. Mistake during implementation
• 1c. Backend bug
• 1z. Other:

Where bug was reported:

• 2a. Reported on production (eg. bug slipped through the normal regression and PR testing process on staging)
• 2b. Reported on staging (eg. found during regression or PR testing)
• 2d. Reported on a PR
• 2z. Other:

Who reported the bug:

• 3a. Expensify user
• 3b. Expensify employee
• 3c. Contributor
• 3d. QA
• 3z. Other:

• [Contributor] 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: NA. It wasn't caused by a recent PR. Instead, it's just a minor issue we want to polish.

• [Contributor] If the regression was CRITICAL (e.g. interrupts a core flow) A discussion in #expensify-open-source 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: NA

• [Contributor] If it was decided to create a regression test for the bug, please propose the regression test steps using the template below to ensure the same bug will not reach production again.

  This is a minor UI polish, so I don't think a regression test is needed here.

• [BugZero Assignee] Create a GH issue for creating/updating the regression test once above steps have been agreed upon.

[CortneyOfstad]

Payment Summary

@FitseTLT — paid $250 via Upwork
@eh2077 — to be paid $250 via NewDot

Regression Test

Indicated here regression test is not needed