[HOLD for payment 2025-01-22] [$250] Android - Attachments - Typing is not smooth when revealing password in 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: 9.0.69-1
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught on HybridApp, is this reproducible on New Expensify Standalone?: Y
If this was caught during regression testing, add the test name, ID and link from TestRail: https://expensify.testrail.io/index.php?/tests/view/5284678&group_by=cases:section_id&group_order=asc&group_id=292107
Email or phone of affected tester (no customers): ibellicotest+57@gmail.com*
Issue reported by: Applause - Internal Team

Action Performed:

1. Open the Expensify app
2. Open any chat
3. Tap on the "+" button and select "Add File"
4. Select a PDF that is protected with a password
5. Tap on "Enter the password"
6. Tap on the eye icon to reveal the password
7. Start typing the password in a fast manner
8. Verify that each character is added smoothly

Expected Result:

When typing the PDF password after revealing it, each character should be added smotthly

Actual Result:

Typing is not smooth when typing PDF password after revealing it. When typing in a fast manner, not every character is added to password

Workaround:

Unknown

Platforms:

Which of our officially supported platforms is this issue occurring on?

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

Screenshots/Videos

Add any screenshot/video evidence

Bug6680924_1733004068289.Pass_PDF.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021866173601902671628
• Upwork Job ID: 1866173601902671628
• Last Price Increase: 2025-01-06

Issue Owner

Current Issue Owner: @johncschuster

[melvin-bot]

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

[melvin-bot]

@johncschuster Whoops! This issue is 2 days overdue. Let's get this updated quick!

[johncschuster]

I couldn't action this today. I will check it out this weekend.

[melvin-bot]

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

[melvin-bot]

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

[rohit9625]

Proposal

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

Typing is not smooth when revealing password in protected PDF. On Android, the keyboard flickers when typing the password in the revealed state.

What is the root cause of that problem?

React Native’s TextInput automatically switches the keyboard type on Android based on the secureTextEntry prop. See this comment that shows the behavior for both IOS and Android when keyboardType=numeric.

We are using the getSecureEntryKeyboardType method to determine the keyboard here:

App/src/components/TextInput/BaseTextInput/index.native.tsx

Line 370 in f481d64

keyboardType={getSecureEntryKeyboardType(inputProps.keyboardType, inputProps.secureTextEntry ?? false, passwordHidden ?? false)}

This is the method responsible for determining keyboard type on Android devices:-

The keyboardType='visible-password' conflicts with the default behavior of switching keyboard type on Android. It results in the flickering keyboard that can be seen in this screencast below:-

Observe the emoji icon button and the mic button.

Issue_Repro.mp4

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

We should not use the native getSecureEntryKeyboardType method to determine keyboardType based on passwordHidden and secureTextEntry parameters on Android devices, instead we should use directly assign

keyboardType={inputProps.keyboardType}

It fixes the issue as seen in the screencast

Issue_Solution.mp4

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

1. We can add tests, if not already, for the native getSecureEntryKeyboardType method ensuring that it returns the passed keyboardType prop as it is, if prefer refactoring similar to the method in src/libs/getSecureEntryKeyboardType/index.ts file.

2. Otherwise, just get rid of that index.android.ts file and write tests, if not already, for the method in src/libs/getSecureEntryKeyboardType/index.ts.

What alternative solutions did you explore? (Optional)

1. Alternatively, we can also pass the inputMethod prop as text to the TextInput component in PDFPasswordForm.tsx
   Because the inputMethod prop has precedence over the keyboardType prop and hence will ignore the keyboardType=visible-password. See this ref

2. However, I would suggest removing the usage of the native getSecureEntryKeyboardType method because this is getting called on each keystroke(verified by log statements). We already have the same method that directly returns the passed keyboardType prop which is being used for Web/Desktop/IOS/.

[jjcoffee]

@rohit9625 Thanks for the proposal! What version of Android are you able to reproduce the issue on? For me on Android 14 (API 34) I don't see the issue.

Your solution would introduce a regression from the fix implemented in #9593, which was added to prevent the keyboard from visibly switching when toggling the password visibility (which you can see happens in your solution video).

[rohit9625]

What version of Android are you able to reproduce the issue on? For me on Android 14 (API 34) I don't see the issue.

I tested this issue on my Samsung A14 Device with Android 14(API 34).

Your solution would introduce a regression from the fix implemented in #9593, which was added to prevent the keyboard from visibly switching when toggling the password visibility (which you can see happens in your solution video).

I'm looking into it. How can I access that password input screen while login? For now, I'm being redirected to the Magic Code screen.

[jjcoffee]

@rohit9625 Huh, strange that I can't reproduce it on the same API version. Does it happen for you in an emulator too?

How can I access that password input screen while login?

That no longer exists in the app, but the behaviour is the same in the PDF password input since it's the same base component.

[rohit9625]

@jjcoffee, I haven't tried it on an emulator yet. I'll try and let you know.

[rohit9625]

Hey @jjcoffee, I tried running the app on the emulator as well with API 34 and still facing the same issue. See the screencast below:-

Screencast.from.2024-12-11.23-23-34.mp4

I think that toggling secureTextEntry automatically switches the keyboardType as I mentioned in my proposal. Currently, we are forcing keyboardType='visible-password' when the password is not hidden which is redundant. Please correct me if I'm wrong.

App/src/libs/getSecureEntryKeyboardType/index.android.ts

Lines 8 to 9 in 20b4c7d

	const getSecureEntryKeyboardType: GetSecureEntryKeyboardType = (keyboardType, secureTextEntry, passwordHidden) =>
	secureTextEntry && !passwordHidden ? CONST.KEYBOARD_TYPE.VISIBLE_PASSWORD : keyboardType;

I guess the behavior in my solution video is obvious. The same behavior can be seen for Facebook Android app below:-

Screen_recording_20241211_232756.mp4

This is the screencast from the emulator after the fix I mentioned. The behavior in the screencast was the issue that this #9593 has solved.

Screencast.from.2024-12-11.23-46-45.mp4

I think we cannot prevent this keyboard switching because this is the library's issue. However, when secureTextEntry={true} the keyboard prevents autoCorrect and autoComplete but it allows that when secureTextEntry={false}.

[jjcoffee]

Thanks for the extra testing @rohit9625! I think I'm not quite convinced by the RCA in your proposal, as the behaviour is that the keyboard is switching whilst typing, which doesn't seem to be explained by setting keyboardType='visible-password' (unless this is some sort of known bug).

@johncschuster Do you think it's an acceptable fix if the keyboard changes once you switch between visible/invisible modes? It's technically a regression from #9593, but it's visually less disturbing than the keyboard changing whilst you type, I think.

[melvin-bot]

@johncschuster @jjcoffee 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!

[melvin-bot]

@johncschuster, @jjcoffee Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!

[jjcoffee]

@johncschuster Friendly bump on this question 🙏

[jjcoffee]

@rohit9625 Please proceed with the PR. Being assigned here guarantees that you've got the job - there is just sometimes a delay before you get hired on Upwork.

[jjcoffee]

PR is testing well, but I'm blocked on testing on iOS Safari due to a bug which means PDFs aren't loading. I'm asking on Slack in case it's something to do with my setup.

[rohit9625]

The PR is merged but I didn't received offer on Upwork yet.

[jjcoffee]

@rohit9625 You will most likely receive an offer once the regression period is over (7 days after the PR hits production). cc @johncschuster for confirmation.

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

• Fix keyboard flickering and bad typing behavior while typing password in revealed state for a protected PDF #55130

If no regressions arise, payment will be issued on 2025-01-22. 🎊

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

• @jjcoffee requires payment through NewDot Manual Requests
• @rohit9625 requires payment (Needs manual offer from BZ)

[melvin-bot]

@jjcoffee @johncschuster @jjcoffee 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]

[johncschuster]

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:

• [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:

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

Regression Test Proposal Template

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

  Link to issue:

Regression Test Proposal

Precondition:

Test:

Do we agree 👍 or 👎

[johncschuster]

Payment Summary (to be paid after regression window has passed)

Contributor: @rohit9625 paid $250 via Upwork
Contributor+: @jjcoffee owed $250 via NewDot

[rohit9625]

Thanks 😊
I received the offer.

[melvin-bot]

Payment Summary

Upwork Job

• Reviewer: @jjcoffee owed $250 via NewDot
• ROLE: @rohit9625 paid $(AMOUNT) via Upwork (LINK)

BugZero Checklist (@johncschuster)

• I have verified the correct assignees and roles are listed above and updated the neccesary manual offers
• I have verified that there are no duplicate or incorrect contracts on Upwork for this job (https://www.upwork.com/ab/applicants/1866173601902671628/hired)
• I have paid out the Upwork contracts or cancelled the ones that are incorrect
• I have verified the payment summary above is correct

[jjcoffee]

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: fix: secure text become visible keep keyboard unchanged #9593 (comment)

• [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: N/A

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

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

  Link to issue:

Regression Test Proposal

Precondition:

Test:

1. Open any chat
2. Tap on the "+" button and select "Add File"
3. Select a PDF that is protected with a password
4. Tap on "Enter the password"
5. Tap on the eye icon to reveal the password
6. Start typing characters quickly
7. Verify that the keyboard does not flicker and typing is smooth, with all characters added

Do we agree 👍 or 👎

[rohit9625]

Do I have to do something else?

[johncschuster]

Payment has been issued to @rohit9625! @jjcoffee, please request payment via ND!

[garrettmknight]

$250 approved for @jjcoffee