Report fields - After creating report field, Add field button is stuck and partially blocked

[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.70-0
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #99308
Email or phone of affected tester (no customers): jsdoijnodsdisojo@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.5 / Chrome
App Component: Workspace Settings

Action Performed:

1. Go to staging.new.expensify.com
2. Create a Control workspace.
3. Go to workspace settings > Reports.
4. Enable Report fields.
5. Click Add field.
6. Enter name and select Text type.
7. Click Save.

Expected Result:

After creating report field, Add field button will animate down smoothly.

Actual Result:

After creating report field, Add field button is stuck and partially blocked.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7250463_1788462769649.4.mp4

View all open jobs on GitHub

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

[applause-bot]

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

[melvin-bot]

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

[melvin-bot]

@trjExpensify @NicolasBonet @dmkt9 you have been assigned to this deploy blocker because you reviewed the offending PR: #99308

[github-actions]

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

[melvin-bot]

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

[MelvinBot]

🔍 Investigation Summary

Classification: Frontend bug
Causing PR: #99829 - "Accordion: Reset toggled-state so we don't keep animating the accordion on remount" by @s77rt (High confidence)
Related Issues: #99821 (the issue #99829 was fixing), #100332 (StagingDeployCash)

Recommendation: REVERT

#99829 makes the web Accordion stop driving its own height, and Reanimated on web cannot clear an inline height that it already set — so the accordion is frozen at the height it had when the open animation finished, and any content added afterwards (the new report field row) overflows instead of pushing "Add field" down. The PR is a small, isolated 2-file change that nothing has touched since, so it reverts cleanly.

Not the cause: #99308. It was linked by the Applause report and Melvin auto-assigned its contributors, but its only change to the report fields UI is gating logic (!hasAccountingConnections && canWriteReportFields → canWriteReportFields for the "Add field" row, and swapping the toggle's disabled condition). It touches no layout, animation, or list-rendering code, and on the repro's brand-new Control workspace hasAccountingConnections was already false, so the rendered output is identical before and after that PR. @trjExpensify @NicolasBonet @dmkt9 — you can unassign yourselves.

Assigned: @s77rt (PR author), @JmillsExpensify, @truph01, @lakchote (approving reviewers) from highest-confidence causing PR only
Labels: No changes. DeployBlockerCash is correct and stays (App-side regression, fix belongs in Expensify/App). DeployBlocker was not present, so nothing to remove.

📋 Detailed Analysis

Evidence

• Reproducible on staging (9.4.70-0), not on production (9.4.69-1). #99829 merged 2026-09-03T17:49Z and is in the 9.4.70-0 checklist; the bug was reported at 19:31Z the same day. It is not in production yet, which matches exactly.
• I scanned every other PR in the 9.4.70 checklist (plus the Internal QA PRs) for files matching Accordion, useAccordionAnimation, ToggleSettingsOptionRow, FlashList, reanimated, ScrollView, SafeArea, or workspace/reports. #99829 is the only PR in the release that touches the Accordion path, and #99308 is the only other one touching the Reports page at all.
• The reported platforms are Windows/Mac Chrome. The bug is web-only, and #99829 applied its change to both index.tsx and index.native.tsx — but only the web variant has the faulty undefined branch (see Root Cause). That the symptom is web-only is itself strong evidence for this file.
• The "Expected Result" in the report ("Add field button will animate down smoothly") is precisely the pre-#99829 behavior: isToggleTriggered used to stay true forever, so derivedHeight kept re-running withTiming(height) on every content-size change.

Verification

Render chain for the affected UI, confirmed by reading the code:

• WorkspaceReportsPage.tsx#L331-L355 — the report fields FlashList and the "Add field" MenuItem are both passed as subMenuItems.
• ToggleSettingsOptionRow.tsx#L310-L316 — subMenuItems is rendered inside <Accordion isToggleTriggered={shouldAnimateAccordionSection}>.
• Accordion/index.tsx — the file #99829 modified.

git log for src/components/Accordion/index.tsx shows the #99829 commit (57c1cd7) is the most recent change to the file; the one before it is from 2026-07-03. A revert applies cleanly.

Root Cause

The bug is the interaction between the new reset and the web-only undefined branch.

#99829 added this to the opacity animation callback — Accordion/index.tsx#L59-L60:

// Reset the toggled-state so we don't keep animating the accordion on remount
isToggleTriggered.set(false);

That flips the component into this pre-existing branch of useAnimatedStyle — Accordion/index.tsx#L79-L84:

height: !isToggleTriggered.get() ? undefined : derivedHeight.get(),
maxHeight: !isToggleTriggered.get() ? undefined : derivedHeight.get(),
opacity: derivedOpacity.get(),
overflow: isAnimating.get() ? 'hidden' : 'visible',

undefined here is intended to mean "release the height, let the content size itself naturally". On web it does not do that. Reanimated's web prop updater merges the new style over previousStyle and hands it to react-native-web's createReactDOMStyle, which skips every entry whose value is == null before the updater writes the remaining keys onto element.style. So height: undefined doesn't reset anything — it just means nothing is written, and the last numeric height/max-height px value from the open animation stays as an inline style on the DOM node forever.

Step by step for the repro:

1. Toggle Report fields on → isToggleTriggered = true, accordion animates 0 → H (H = height with an empty field list). Each frame writes an inline height: …px; max-height: …px.
2. Animation finishes → new callback sets isToggleTriggered = false.
3. useAnimatedStyle re-runs and emits height: undefined, maxHeight: undefined, overflow: 'visible'. height/maxHeight are dropped by createReactDOMStyle, so the element keeps height: Hpx; max-height: Hpx.
4. User saves a new report field. The inner View grows to H2 > H, but the outer Animated.View is still pinned at H. Because overflow is now visible, the extra content isn't clipped — it spills outside the container while the layout below stays put. Result: the "Add field" button doesn't animate down ("stuck") and renders overlapping the section boundary ("partially blocked").

The native variant is unaffected because it never returns undefined — Accordion/index.native.tsx#L72-L76 returns the measured height.get() in the same branch, which is why the regression is web-only.

If you'd rather roll forward than revert (to keep the #99821 fix), the minimal change is to make the web variant stop emitting undefined in that branch and instead emit a value RNW will actually write — either mirror native and return the measured height.get() for height/maxHeight, or return explicit CSS resets (height: 'auto', maxHeight: 'none') so the stale px value is overwritten. I still recommend the revert for the deploy: #99821 is a comparatively minor unwanted-animation bug that is already the status quo in production, and the forward fix deserves normal review and cross-platform testing rather than being rushed onto a blocked deploy.

---

💡 Suggested AI code review rule

This bug looks like a recurring, mechanically detectable pattern, so it may be worth a coding-standards rule so the AI reviewer catches the next one. Proposed for Expensify/App:

• Rule: UI-4 Never return undefined for a style property from useAnimatedStyle
• Condition: Flag a useAnimatedStyle/useDerivedValue style object that conditionally resolves a property to undefined when another branch of the same style gives that property a concrete value. Return an explicit reset instead ('auto', 'none', 0, or the measured value), because undefined cannot clear a value that was already committed.
• Why: Reanimated's web updater passes the merged style through react-native-web's createReactDOMStyle, which skips null/undefined entries, so the previously written inline value is never cleared and the element stays frozen at its last animated size. Native and web diverge silently, so it slips through native-only testing. Incident: this issue (Report fields - After creating report field, Add field button is stuck and partially blocked #100351).
• Search pattern: rg -n --multiline --include='*.tsx' 'useAnimatedStyle\(\(\) => \{[\s\S]{0,800}?undefined', or AST: an ObjectProperty whose value is undefined (directly, or as a branch of a ConditionalExpression) inside the object returned from a useAnimatedStyle worklet.
• Offending code (❌): src/components/Accordion/index.tsx#L79-L82
• Fix (✅): the equivalent native branch, which returns the measured height rather than undefined — src/components/Accordion/index.native.tsx#L72-L76

The full rule file, with the ❌/✅ code inline in Expensify/App's coding-standards format (.claude/skills/coding-standards/rules/ui-4-*.md plus a SKILL.md bullet under UI), would go in Expensify/App itself. If it's worth adding, a maintainer can open it there as a draft PR.