[$250] [Sentry: APP-C26] Web initialFocus invalid node crash on /home

[mountiny]

Sentry

https://expensify.sentry.io/issues/APP-C26

Impact (snapshot at filing)

• Users (total since first seen): 153
• Events: 171
• Users (last 14d): ongoing on 9.3.89–9.3.91
• First seen: ~28 days ago
• Last seen: now (ongoing)
• Platform: web
• App version(s): seen through 9.3.91
• Affected route(s) (parameterized): /home
• Mechanism: unhandled error (React focus)

Stack trace (top frames, first-party only)

Error: `initialFocus` was specified but was not a node, or did not return a node
  Culprit: /home

Suspected cause

Focus management passes an initialFocus target that is not a mounted DOM node when /home renders (React Aria / composer focus integration).

Reproduction

Unknown deterministically — see Sentry events on /home for session context.

Related

• Sibling Sentry IDs (if any): none identified
• Prior GH issues: App#20067 is unrelated (different bug)
• Production scan: releases 9.3.89, 9.3.90, 9.3.91 (2026-06-02)

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022061885291062280782
• Upwork Job ID: 2061885291062280782
• Last Price Increase: 2026-06-02

Issue Owner

Current Issue Owner: @trasnake87

[melvin-bot]

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

[melvin-bot]

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

[moxw]

Proposal

What is the root cause of that problem?

On small-screen web, shared modal callers such as popovers and selection-list action sheets render as CONST.MODAL.MODAL_TYPE.BOTTOM_DOCKED. BaseModal then overrides the modal initialFocus with:

() => bottomDockedDismissButtonRef.current

That value is passed straight through ReanimatedModal into FocusTrapForModal and then into focus-trap-react.

focus-trap allows initialFocus: false, but if an initialFocus function is provided it must return a valid DOM focus target or false. During bottom-docked modal activation the dismiss button ref can still be null, undefined, or a React Native host ref that is not a DOM Element. In that case focus-trap throws exactly this Sentry error:

initialFocus was specified but was not a node, or did not return a node

The route stays /home because these bottom-docked modals/popovers are opened over the home screen.

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

Normalize modal initialFocus before passing it to FocusTrap.

Concretely:

1. In FocusTrapForModal, wrap the supplied initialFocus option with a safe resolver.
2. If the resolved value is false, keep false.
3. If it is a selector string or a real Element, pass it through.
4. If it is null, undefined, or any non-DOM object, return false instead of letting focus-trap throw.
5. Keep the existing fallbackFocus behavior unchanged.

That protects both the current bottom-docked dismiss-button path and any other modal caller that accidentally provides a stale/non-DOM React Native ref.

We should also update BaseModal’s bottom-docked dismiss-button initialFocus path to be explicit about the contract, e.g. return false unless bottomDockedDismissButtonRef.current is a valid DOM element on web. This keeps the shared modal layer from passing an invalid target in the first place.

For tests, add a focused regression test around the modal focus trap behavior:

• render/activate FocusTrapForModal with initialFocus={() => null} and assert it does not throw;
• render/activate it with initialFocus={() => ({}) as never} and assert it does not throw;
• render/activate it with a real button/div element and assert that valid targets still pass through;
• optionally cover a bottom-docked Modal with isVisible, onClose, and small-screen layout mocked so the dismiss-button initialFocus path is exercised.

What alternative solutions did you explore? (Optional)

Only fixing one caller, such as a specific /home popover, would leave the same crash available through every other small-screen web bottom-docked modal. Returning document.body for invalid initialFocus is also not ideal because the focus target may be outside the trap container; returning false matches the library-supported way to opt out of initial focus when no valid target is available.

[MelvinBot]

Proposal

What is the root cause of that problem?

The crash comes from the focus-trap library (via focus-trap-react), not React Aria as the issue body guessed. focus-trap throws this exact string in getNodeForOption when an initialFocus value (or a function passed as initialFocus) resolves to null, '', or 0 — i.e. any falsy value that is not undefined and not false.

The only initialFocus in the codebase that is a function and is not guarded against returning null is in BaseModal.tsx:322:

const modalInitialFocus = shouldShowBottomDockedDismissButton ? () => bottomDockedDismissButtonRef.current : initialFocus;

bottomDockedDismissButtonRef is attached to a PressableWithoutFeedback that is conditionally rendered (BaseModal.tsx:401-403). When the focus trap activates before that element has committed its ref (mount/animation timing, or a re-render that flips shouldShowBottomDockedDismissButton), bottomDockedDismissButtonRef.current is null, the function returns null, and focus-trap throws.

This path requires shouldShowBottomDockedDismissButton, which is isSmallScreenWidth && type === BOTTOM_DOCKED && (onBackdropPress ?? onClose) — consistent with the web//home + bottom-docked-modal-on-small-screen signature in Sentry.

Evidence & alternatives considered

• Throw site: focus-trap/index.js getNodeForOption (node_modules/focus-trap/index.js:245-247). It only throws for falsy-but-not-undefined/false values; a function returning false returns early at getInitialFocusNode and is safe.
• The sibling AttachmentModalContainer/index.tsx:46-51 uses the same function pattern but explicitly guards: if (!contentProps.submitRef?.current) { return false; }. This proves the team already knows ref-returning initialFocus functions can be null — BaseModal simply missed the guard.
• FocusTrapForScreen defaults to initialFocus: false (safe), and no screen passes a focusTrapOptions.initialFocus override, so the screen-level trap is ruled out.
• Other initialFocus* hits are initialFocusedIndex (arrow-key manager, unrelated) or pass-through props.
• FocusTrapOptions['initialFocus'] accepts false (focus-trap/index.d.ts:123), so returning false is type-safe and is the documented "no initial focus" value.

Confidence: High on the mechanism (error string + unguarded function are an exact match). The provided Sentry frames are minified and only show Culprit: /home, so a contributor should confirm the component with source maps or a repro before merge.

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

Guard the BaseModal initialFocus function so it returns false (focus-trap's "no initial focus" sentinel, which falls back to fallbackFocus) instead of null when the ref isn't attached yet — mirroring the existing AttachmentModalContainer pattern:

const modalInitialFocus = shouldShowBottomDockedDismissButton ? () => bottomDockedDismissButtonRef.current ?? false : initialFocus;

What alternative solutions did you explore? (Optional)

None needed — returning false is the library's supported way to express "no initial focus." An alternative would be widening the guard to any function-form initialFocus, but the single-line fix at the source is sufficient and matches existing conventions.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/92415) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.