[$250] Attachment - Keyboard doesn't close after entering password of protected PDF

[lanitochka17]

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: v9.3.41-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: https://test-management.browserstack.com/projects/2219752/test-runs/TR-10912/folder/13176710/41236945/1264592220
Email or phone of affected tester (no customers): testpayment935@gmail.com
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: Samsung s10/ Android 12
App Component: Chat Report View

Action Performed:

1. Open Android app
2. Send a password protected PDF (attached)
3. Open the PDF
4. Click on enter password
5. Enter the password (Test12345) and click confirm

Expected Result:

Keyboard should close after entering password

Actual Result:

Keyboard doesn't close after entering password of protected PDF

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7107824_1773962957025.Screen_Recording_20260320_022351_Expensify.mp4

Bug7107824_1773962957014!PDF_Password_protected_Test12345.pdf

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @war-in

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022034926955652862644
• Upwork Job ID: 2034926955652862644
• Last Price Increase: 2026-03-20

[melvin-bot]

Triggered auto assignment to @Gonals (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

[melvin-bot]

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

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

[OSBotify]

Investigation Summary

Classification: Frontend bug
Causing PR: #79962 - "Upgrade React Native to v0.83" by @war-in (High confidence)
Related Issues: None

Recommendation: ROLL FORWARD

The React Native 0.83 upgrade is a major framework update that affects the entire app. Reverting would reintroduce significant complexity and block other improvements that depend on RN 0.83. A targeted fix for the keyboard dismissal behavior on Android is the better path forward.

Labels: Keeping DeployBlockerCash - this is a frontend (App) bug requiring a fix in the App repository.

Detailed Analysis

Evidence

The bug reproduces on staging (v9.3.41-0) but not on production, indicating a regression introduced by a PR in the staging deploy. PR #79962 upgrades React Native from v0.81 to v0.83, which includes substantial changes to Android keyboard handling and input behavior.

The affected code path:

• User opens password-protected PDF on Android app
• User enters password in PDFPasswordForm TextInput
• User taps "Confirm" button or presses Enter
• Expected: Keyboard dismisses automatically after submission
• Actual: Keyboard stays open

Verification

1. PR Upgrade React Native to v0.83 #79962 is confirmed in staging deploy at chronological position Scroll to show new comments #63
2. The PR includes patches to React Native core, including Android TextInput behavior
3. The PDFPasswordForm component uses onSubmitEditing which relies on platform keyboard behavior
4. React Native 0.83 may have changed default keyboard dismissal behavior on form submission

Root Cause

React Native 0.83 likely changed the default behavior for keyboard dismissal when onSubmitEditing is called on Android. The PDFPasswordForm component does not explicitly call Keyboard.dismiss() and relies on the platform default behavior, which may have changed in RN 0.83.

The fix should add explicit Keyboard.dismiss() call in the submitPassword function:

const submitPassword = () => {
    if (!validate()) {
        return;
    }
    Keyboard.dismiss();  // Add this
    onSubmit?.(password);
};

[MelvinBot]

Proposal

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

On Android, after opening a password-protected PDF attachment, entering the password, and tapping "Confirm", the keyboard stays open instead of dismissing. This is a regression in staging v9.3.41-0 that does not occur in production.

What is the root cause of that problem?

The PDF password submission flow has no explicit Keyboard.dismiss() call. It relies entirely on an implicit mechanism: when the password is correct, finishPDFLoad() sets shouldRequestPassword = false, which unmounts the PDFPasswordForm (and its TextInput). On Android with React Native 0.81.4 (production), unmounting a focused TextInput implicitly dismissed the keyboard. With the React Native upgrade from 0.81.4 to 0.83.1 (staging), this implicit behavior no longer works on Android — likely due to the Kotlin conversion of ReactEditText in RN 0.83.

Key evidence:

• submitPassword() in PDFPasswordForm.tsx (line 98-103) calls onSubmit(password) but never calls Keyboard.dismiss()
• attemptPDFLoadWithPassword() in index.native.tsx (line 116-123) sets state but never calls Keyboard.dismiss()
• The ScrollView wrapping the form uses keyboardShouldPersistTaps="handled" (line 107), which explicitly keeps the keyboard open during button taps
• The PDFPasswordForm and PDFView code is identical between production and staging — only the RN version changed
• Other forms in the app (e.g., FormWrapper.tsx line 126) already call Keyboard.dismiss() explicitly on submit

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

Add an explicit Keyboard.dismiss() call in attemptPDFLoadWithPassword in src/components/PDFView/index.native.tsx. This is where the password challenge transitions to loading the PDF, making it the natural place to dismiss the keyboard:

import {Keyboard} from 'react-native';

// In attemptPDFLoadWithPassword:
Keyboard.dismiss();

This follows the same pattern already used by FormWrapper and makes the keyboard dismissal explicit rather than relying on fragile implicit behavior tied to component unmount timing.

What alternative solutions did you explore? (Optional)

1. Adding Keyboard.dismiss() in submitPassword() inside PDFPasswordForm.tsx — This would also work, but placing it in the parent (index.native.tsx) is more appropriate because the parent owns the password flow lifecycle and the form component shouldn't need to know about keyboard management.

2. Adding Keyboard.dismiss() in finishPDFLoad() — This would work but introduces a delay (keyboard only dismisses after the PDF finishes loading with the password). Dismissing immediately on submit provides a better UX.

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, @MelvinBot <your feedback> to refine this analysis, or explain why you are rejecting Melvin's proposal.