Skip to content

Expense - No background blur when Month/Year RHP is opened while editing report field inline #101810

Closed

Description

@applause-bot

If you haven’t already, check out our contributing guidelines for onboarding. To join our Slack channel, fill out this form.


Version Number: 9.4.91-0
Reproducible in staging?: Yes
Reproducible in production?: N/A - new feature, doesn't exist in prod
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #100735
Email or phone of affected tester (no customers): sjodjoijsonjoinj@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.5 / Chrome
App Component: Money Requests

Action Performed:

Precondition:

  • Create a date type report field
  1. Go to staging.new.expensify.com
  2. Go to workspace chat.
  3. Create an expense.
  4. Open the expense.
  5. Click Date report field.
  6. Click month or year.

Expected Result:

There will be background blur when Month/Year RHP is opened while editing report field inline.

Actual Result:

There is no background blur when Month/Year RHP is opened while editing report field inline.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7265674_1790019360010.2.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Svetlana Lazutkina
Bug ID: 7265674

Activity

  1. added
    DeployBlockerCashThis issue or pull request should block deployment
    BugSomething is broken. Auto assigns a BugZero manager.
    on Sep 21, 2026
  2. applause-bot commented on Sep 21, 2026

    @applause-bot
    Author

    While Applause doesn't embed attachments for this bug, here are the links for quick view:
    https://platform.applause.com/services/links/v1/external/bc8c44f245ef148f28e5be27d981ec2d9c61a851f690f045c909182920d40129

  3. melvin-bot commented on Sep 21, 2026

    @melvin-bot

    You have been assigned to this deploy blocker because you recently merged this PR: #100735

  4. github-actions commented on Sep 21, 2026

    @github-actions
    Contributor

    👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

    1. Identify the pull request that introduced this issue and revert it.
    2. Find someone who can quickly fix the issue.
    3. Fix the issue yourself.
  5. melvin-bot commented on Sep 21, 2026

    @melvin-bot

    @Gonals @daledah you have been assigned to this deploy blocker because you reviewed the offending PR: #100735

  6. melvin-bot commented on Sep 21, 2026

    @melvin-bot

    💬 A slack conversation has been started in #expensify-open-source

  7. MelvinBot commented on Sep 21, 2026

    @MelvinBot
    Contributor

    🔍 Investigation Summary

    Classification: Frontend bug
    Causing PR: Show up to three report fields per row and edit them inline (Expensify/App#100735) — merged 2026-09-21, part of the 9.4.91-0 checklist (High confidence)
    Related Issues: Deploy Checklist: New Expensify 2026-09-21

    Recommendation: ROLL FORWARD

    The offending PR is the large inline report-field editing feature, and the defect is one missing opt-in prop (shouldEnableMonthYearBackdropInNarrowPane) that an existing inline date-editing flow already sets — a two-line fix is far safer than reverting the whole feature.

    Assigned: @Gonals and @daledah (approving reviewers of Expensify/App#100735) — already assigned. The PR author is a bot account, so there is no human author to add.
    Labels: No changes. DeployBlockerCash is kept (App-side fix). DeployBlocker was not present and was not added.

    📋 Detailed Analysis

    Evidence

    • The bug only exists on staging and is explicitly "N/A - new feature, doesn't exist in prod". The feature being exercised — editing a date report field inline from the expense report view — was introduced by Expensify/App#100735, which added ReportFieldInlineInput.tsx and rewired MoneyRequestViewReportFields from MenuItemWithTopDescription rows (which navigated to the edit page) to in-place inputs.
    • Before that PR, clicking a Date report field navigated to the EDIT_REPORT_FIELD page, so the calendar (and its Month/Year picker) never opened from inside the report view — there was no prior behavior to regress. This is a new-feature gap, not a regression of existing code.
    • The last three commits touching src/components/DatePicker/index.tsx are all from that PR's branch (claude-reportFieldsGridInlineEditing). Nothing else in the 9.4.91 checklist touches the date picker or the modal backdrop logic; the only recent BaseModal.tsx change (2026-09-11, wide search router scrim) is purely additive (shouldShowBackdrop opt-in) and does not affect this path.

    Verification

    Affected files (all in Expensify/App, all touched or introduced by Expensify/App#100735):

    Root Cause

    The Month/Year pickers are RIGHT_DOCKED modals (YearPickerModal.tsx#L61-L72, MonthPickerModal.tsx#L74). BaseModal deliberately suppresses the backdrop for a right-docked modal opened inside a narrow pane:

    // src/components/Modal/BaseModal.tsx:301-308
    const shouldSuppressRightDockedBackdrop =
        type === CONST.MODAL.MODAL_TYPE.RIGHT_DOCKED && !isSmallScreenWidth && (isInNarrowPane || isInNarrowPaneModal) && !shouldKeepRightDockedBackdropInNarrowPane;

    (BaseModal.tsx#L299-L308)

    The expense report view is a RightModalNavigator screen, and that navigator wraps its content in NarrowPaneContextProvider, so isInNarrowPane is true for every modal opened from the report fields. On a wide screen (!isSmallScreenWidth, which matches the reported Windows/macOS Chrome repro) the condition above is satisfied and backdropOpacityAdjusted becomes 0 — no dim, no blur.

    The escape hatch already exists and is threaded all the way down: DatePickerModal → CalendarPicker → Year/MonthPickerModal → shouldKeepRightDockedBackdropInNarrowPane (DatePickerModal.tsx#L48, DatePickerModal.tsx#L105, CalendarPicker/index.tsx#L435-L449). The Search list's inline date editing already opts in:

    // src/components/Search/SearchList/ListItem/DateCell.tsx:84
    shouldEnableMonthYearBackdropInNarrowPane={isEditing && isInNarrowPaneModal}

    (DateCell.tsx#L84)

    That call site uses DatePickerModal directly. The new inline report field goes through the DatePicker wrapper instead, and the wrapper drops the prop on the floor, so there was no working way to opt in.

    Suggested fix (two changes, both in Expensify/App)

    1. src/components/DatePicker/index.tsx: destructure shouldEnableMonthYearBackdropInNarrowPane (already declared on DatePickerBaseProps) and forward it to <DatePickerModal>.
    2. src/components/MoneyRequestReportView/ReportFieldInlineInput.tsx: pass shouldEnableMonthYearBackdropInNarrowPane={isInNarrowPaneModal} (from useResponsiveLayout) on the date branch, mirroring DateCell. Report fields rendered in the central-pane MoneyReportView are unaffected, since isInNarrowPaneModal is false there and the backdrop already shows.
  8. melvin-bot commented on Sep 22, 2026

    @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.

  9. Gonals commented on Sep 22, 2026

    @Gonals
    Contributor

    PR Reverted

  10. IuliiaHerets commented on Sep 22, 2026

    @IuliiaHerets

    Chrome / 9.4.91-1
    Passed

    bandicam.2026-09-22.13-49-30-245.mp4
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

BugSomething is broken. Auto assigns a BugZero manager.EngineeringReviewingHas a PR in review

Type

No type

Projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions