[HOLD for payment 2025-01-02] [$250] iOS - Profile - Display Name - Keyboard blinks when focus is changed

[lanitochka17]

If you haven’t already, check out our contributing guidelines for onboarding and email [email protected] to request to join our Slack channel!

---

Version Number: 9.0.66-3
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: N/A
Issue reported by: Applause - Internal Team

Action Performed:

1. Open the mobile app on iOS
2. Navigate to settings > profile > display name
3. Tap into First Name so that the keyboard pulls up
4. Tap into Last Name (keyboard should stay up)
5. Tap between FN and LN a few times

Expected Result:

Keyboard shouldn’t blink when focus is changed

Actual Result:

Keyboard blinks when focus is changed

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

Bug6642786_1729655434200.E-16685.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021861288508956384711
• Upwork Job ID: 1861288508956384711
• Last Price Increase: 2024-12-10
• Automatic offers:
• DylanDylann | Reviewer | 105347513

Issue Owner

Current Issue Owner: @kadiealexander

[melvin-bot]

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

[jliexpensify]

ios <> Android swap

[Shahidullah-Muffakir]

Edited by proposal-police: This proposal was edited at 2024-11-25 22:15:00 UTC.

Proposal

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

In the iOS app, users experience keyboard blinking and re-rendering when switching focus between display name input fields (first and last name)

What is the root cause of that problem?

This is an iOS-specific rendering issue where:
facebook/react-native#39411
flutter/flutter#134723

• Native keyboard events trigger unnecessary re-renders
• The AutoFill Bar causes keyboard UI instability
• Likely a low-level interaction between React Native and iOS keyboard rendering mechanisms

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

We have few options as workarounds, root cause is deeply embedded in iOS.
I think the simplest and direct solution would be to use autoCorrect= {false} prop for the first and last names in the DisplayNamePage

App/src/pages/settings/Profile/DisplayNamePage.tsx

Lines 92 to 116 in e4ac07a

	<InputWrapper
	InputComponent={TextInput}
	inputID={INPUT_IDS.FIRST_NAME}
	name="fname"
	label={translate('common.firstName')}
	aria-label={translate('common.firstName')}
	role={CONST.ROLE.PRESENTATION}
	defaultValue={currentUserDetails.firstName ?? ''}
	spellCheck={false}
	isMarkdownEnabled
	/>
	</View>
	<View>
	<InputWrapper
	InputComponent={TextInput}
	inputID={INPUT_IDS.LAST_NAME}
	name="lname"
	label={translate('common.lastName')}
	aria-label={translate('common.lastName')}
	role={CONST.ROLE.PRESENTATION}
	defaultValue={currentUserDetails.lastName ?? ''}
	spellCheck={false}
	isMarkdownEnabled
	/>
	</View>

Trade-offs to consider:

1. Disables text suggestions and autocorrect for first and last name fields
2. Acceptable in this context, as display names typically require precise spelling

we can use Platform.OS === 'ios'if we want to conditionally apply this only for iOS

What alternative solutions did you explore? (Optional)

Another approach involves modifying the React Native KeyboardAvoidingView implementation. we are using KeyboardAvoidingView in ScreenWrapper

App/src/components/ScreenWrapper.tsx

Line 278 in b4876bc

<KeyboardAvoidingView

we will add a custom prop ignoreIOSKeyboardWillChangeEvents for iOS to selectively prevent
problematic keyboard re-render events.
facebook/react-native#39411 (comment)

Screen.Recording.2024-11-26.at.3.08.43.AM.mov

[melvin-bot]

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

[melvin-bot]

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

[huult]

Edited by proposal-police: This proposal was edited at 2024-11-26 15:56:42 UTC.

Proposal

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

Keyboard blinks when focus is changed

What is the root cause of that problem?

The soft keyboard briefly resets when switching between input fields. This occurs due to the autoCapitalize behavior in React Native's TextInput. Initially, the keyboard defaults to uppercase but adjusts to lowercase after recognizing the input state.

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

Using the autoCapitalize property set to words for the First Name and Last Name inputs resolves the issue while retaining auto-capitalization functionality. like this ticket #16685 . Some thing like that:

App/src/pages/settings/Profile/DisplayNamePage.tsx

Line 92 in 4713c7e

<InputWrapper

App/src/pages/settings/Profile/DisplayNamePage.tsx

Line 105 in 4713c7e

<InputWrapper

src/pages/settings/Profile/DisplayNamePage.tsx#L94
                      <View style={styles.mb4}>
                        <InputWrapper
                            InputComponent={TextInput}
                            inputID={INPUT_IDS.FIRST_NAME}
                            name="fname"
                            label={translate('common.firstName')}
                            aria-label={translate('common.firstName')}
                            role={CONST.ROLE.PRESENTATION}
                            defaultValue={currentUserDetails.firstName ?? ''}
                            spellCheck={false}
                            isMarkdownEnabled
+                            autoCapitalize="words"
                        />
                    </View>
                    <View>
                        <InputWrapper
                            InputComponent={TextInput}
                            inputID={INPUT_IDS.LAST_NAME}
                            name="lname"
                            label={translate('common.lastName')}
                            aria-label={translate('common.lastName')}
                            role={CONST.ROLE.PRESENTATION}
                            defaultValue={currentUserDetails.lastName ?? ''}
                            spellCheck={false}
                            isMarkdownEnabled
+                            autoCapitalize="words"
                        />
                    </View>

Note: If a similar case arises(Legal name), we can reuse this solution

POC

Screen.Recording.2024-11-26.at.22.54.07.mov

What alternative solutions did you explore? (Optional)

Using the keyboardType set to name-phone-pad for the First Name and Last Name inputs resolves the issue.

[DylanDylann]

I can't reproduce this bug on IOS simulators

[DylanDylann]

@huult As per your explanation, I am confused as to why autoCapitalize is removed?

[huult]

@huult As per your explanation, I am confused as to why autoCapitalize is removed?

#25911 We removed this prop with this pull request as it was inconsistent with legal name. So, I think to fix this issue, we should add autoCapitalize for both display name and legal name.

[huult]

I can't reproduce this bug on IOS simulators

@DylanDylann I am still able to reproduce this bug on iOS simulators

Screen.Recording.2024-11-28.at.11.59.40.mov

[DylanDylann]

Hmmm... Or it can be only reproduced on iPhone 16

[DylanDylann]

Can't reproduce on IP 15 pro max (IOS 17.2)

Screen.Recording.2024-11-28.at.12.12.11.mov

[DylanDylann]

The soft keyboard briefly resets when switching between input fields. This occurs due to the autoCapitalize behavior in React Native's TextInput. Initially, the keyboard defaults to uppercase but adjusts to lowercase after recognizing the input state.

Your rCA isn't correct in my case

[huult]

I will try testing the same as your model.

[huult]

@DylanDylann I tested it, and this only happens on iOS 18. When we change the text input field, the keyboard switches to uppercase and then to lowercase.

Screen.Recording.2024-11-28.at.13.12.53.mov

[huult]

Your rCA isn't correct in my case

Since you are using iOS 17.2, this issue does not occur on this version. I initialized a new project and tested it as shown in the video below.

Screen.Recording.2024-11-28.at.13.41.35.mov

[DylanDylann]

This occurs due to the autoCapitalize behavior in React Native's TextInput. Initially, the keyboard defaults to uppercase but adjusts to lowercase after recognizing the input state.

@huult Do you have any reference for this point? the keyboard defaults to uppercase

[DylanDylann]

Another thing, your proposal will change expected behavior that we confirmed before

[DylanDylann]

Also please help to detail why alternative solution will solve this problem

[huult]

@DylanDylann

Do you have any reference for this point? the keyboard defaults to uppercase

facebook/react-native#47997 I posted this issue in the React Native community and hope to get support soon. I searched but did not find any related bug reports.

Another thing, your proposal will change expected behavior that we confirmed before

We asked the design team when I was hired.

Also please help to detail why alternative solution will solve this problem

I found the solution in this ticket: #16685, and we have used the same approach in this case. I believe we can use it as well

[DylanDylann]

We asked the design team when I was hired.

Let's make it clear first, I can't approve proposals that change the expected behavior (maybe cause regression)

[DylanDylann]

@parasharrajat I see the current behavior still matches with the expected. Could you help to point out what regression is here? (if possible please detail it as much as possible)

[rezkiy37]

I just compared the latest main version (9.0.82-1) and a staging one (9.0.67-8). I am attaching screenshots for you.

Details

New

Legacy

[kadiealexander]

@MariaHCD I think this is okay, could you please take a look and confirm?

[MariaHCD]

Thanks for the screenshots, @rezkiy37 - that definitely helps visualize the change :)

Before	After

The change in the size of the emojis have decreased. However, in my opinion, it's a very minor change and the keyboard blinking is a more noticeable UX issue than the size of the emoji.

I also notice that the size of the field labels have increased - is that a side effect of removing isMarkdownEnabled?

My recommendation is to keep our change as is.

Happy to hear thoughts from @parasharrajat @DylanDylann @rezkiy37 if you agree or have concerns.

[rezkiy37]

My recommendation is to keep our change as is.

Agree 👍

[parasharrajat]

Yes, we increased the emoji to look bigger in the old PR as per scene 5. Now, because we removed markdown input, it will behave like normal text and emoji will not look bigger.

If we want to keep this change, then we should update the regression steps to indicate that change and possibly create a slack thread to inform the design team or original proposer who created that issue.

[mvtglobally]

Issue not reproducible during KI retests. (First week)

[kadiealexander]

@Expensify/design this fix makes a change to the size of emojis, would love for you guys to weigh in on whether this is okay.

[dubielzyk-expensify]

Hmm. I don't think the decrease in emoji's is a huge deal. Ideally it should just match the font size and I dunno enough about the technical implications here etc. If we believe this is the only way to get rid of the blinking than this seems fine. Keen to hear the other designers thoughts as well

[shawnborton]

I'm a bit lost when it comes to emoji sizes since things have changed so frequently over the past few months. I agree with Jon's sentiment though - I would imagine that in most cases, the emoji is just the same size as the font we're using. Only in the special cases where the message is just emojis would we increase the size (similar to WhatsApp or Slack).

In the particular change being called out above, how much has the emoji size decreased?

[rezkiy37]

...how much has the emoji size decreased?

Basically, it has been aligned with the text size:

App/src/styles/index.ts

Lines 1230 to 1232 in cdc4c4a

	baseTextInput: {
	...FontUtils.fontFamily.platform.EXP_NEUE,
	fontSize: variables.fontSizeNormal,

App/src/styles/variables.ts

Line 54 in cdc4c4a

fontSizeNormal: getValueUsingPixelRatio(15, 21),

So the default value is 15pt. For instance, the emoji size was 19pt.

[dannymcclain]

I feel the same as Shawn and Jon.

[MariaHCD]

Sounds like we all agree to keep our PR as is 👍🏼

@kadiealexander I think we can move forward here?

[kadiealexander]

Awesome! Payment summary is here for the NewDot payment reviewer.

[DylanDylann]

@kadiealexander I still get paid via Upwork

[kadiealexander]

Ah sorry for that @DylanDylann, I've issued payment and updated the summary.

[shawnborton]

Another issue led me here - I just wanted to confirm, did we end up changing the emoji font size? @rezkiy37 can you confirm and point me to the corresponding PR? Thanks!

[rezkiy37]

@shawnborton, yes, we did. #54293.

[shawnborton]

Can you show me where/how in the PR we are changing the emoji size though? I'm not connecting the dots very well, apologies!

[rezkiy37]

@shawnborton Sure! We've replaced the markdown input with the regular one from RN. I didn't change some styles because the previous input parsed emojis and made them bigger.

[shawnborton]

Ah okay, so basically what happened is that we removed isMarkdownEnabled, which included styles for how emojis are displayed? I don't think I quite understand the connection between the naming, but I trust you that it did the trick :)

[shawnborton]

Actually just tested on staging, and I still see the emojis taking a larger font size... is that expected?

[rezkiy37]

Ah, yeah. We have changed only inputs on the profile display name page. Nowhere else.

[shawnborton]

Ah okay, apologies for misunderstanding and thanks for clarifying!