[$1000] Keyboard closes while selecting members on invite page on mWeb vs keyboard stays open on android

[kavimuru]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Action Performed:

1. Create a workspace and go to invite members page
2. Select users from the list and notice the keyboard behavior on native and on mWeb and compare the two

Expected Result:

keyboard behavior should be consistent between android and mWeb

Actual Result:

keyboard stays open on native but closes on mWeb

Workaround:

Can the user still use Expensify without this being fixed? Have you informed them of the workaround?

Platforms:

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

• Android / native
• Android / Chrome
• iOS / native
• iOS / Safari
• MacOS / Chrome / Safari
• MacOS / Desktop

Version Number: 1.3.38-2
Reproducible in staging?: y
Reproducible in production?: y
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos: Any additional supporting documentation

Screen_Recording_20230708_193224_Chrome.mp4

az_recorder_20230708_232030.1.mp4

Expensify/Expensify Issue URL:
Issue reported by: @Nathan-Mulugeta
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1688834077644289

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~0112a3b6c2cacb43a8
• Upwork Job ID: 1678431603352903680
• Last Price Increase: 2023-07-31

[melvin-bot]

Triggered auto assignment to @puneetlath (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details.

[melvin-bot]

Bug0 Triage Checklist (Main S/O)

• This "bug" occurs on a supported platform (ensure Platforms in OP are ✅)
• This bug is not a duplicate report (check E/App issues and #expensify-bugs)
  • If it is, comment with a link to the original report, close the issue and add any novel details to the original issue instead
• This bug is reproducible using the reproduction steps in the OP. S/O
  • If the reproduction steps are clear and you're unable to reproduce the bug, check with the reporter and QA first, then close the issue.
  • If the reproduction steps aren't clear and you determine the correct steps, please update the OP.
• This issue is filled out as thoroughly and clearly as possible
  • Pay special attention to the title, results, platforms where the bug occurs, and if the bug happens on staging/production.
• I have reviewed and subscribed to the linked Slack conversation to ensure Slack/Github stay in sync

[puneetlath]

Hmm, interesting. I agree this is inconsistent. I wonder if it's because of our own implementation or just the default behavior on native vs browser. In any case I'll mark as external for now for thoughts.

@Nathan-Mulugeta what happens on iOS?

[melvin-bot]

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

[melvin-bot]

Current assignee @puneetlath is eligible for the External assigner, not assigning anyone new.

[melvin-bot]

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

[Nathan-Mulugeta]

I can't test on ios @puneetlath

[tienifr]

Proposal

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

Keyboard stays open on native but closes on mWeb

What is the root cause of that problem?

We currently do not support persisting the keyboard when clicking on options in mWeb. The keyboardShouldPersistTaps is only supported on native platforms, it's not supported on web platform, see here.
The user might want to proceed to add a new contact immediately so we shouldn't blur the input when clicking on options in mWeb.

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

Listen to mouse down event of the option, if the TextInput is currently focused we preventDefault, so that when selecting option it will not blur the TextInput.

Unfortunately, on android we can press arrow down button in your Android device to hide the keyboard, but the input is still focused, so when we use e.preventDefault() we prevent the input blur => the keyboard opens again (just like we focus on the input manually). That why we also need to check the keyboard is open or not.

We need to:

• Add withWindowDimensions HOC and Update componentDidUpdate function in BaseOptionsSelector to detect the keyboard is open or not like what we did in PDFView

    componentDidUpdate(prevProps) {
        if (!this.isKeyboardOpen && this.props.windowHeight < prevProps.windowHeight -100) {
            this.isKeyboardOpen=true
        } else if (this.isKeyboardOpen && this.props.windowHeight > prevProps.windowHeight + 100) {
            this.isKeyboardOpen=false
        }

Here's the reason why we need 100

App/src/components/PDFView/index.js

Lines 38 to 44 in cd851d0

	// Use window height changes to toggle the keyboard. To maintain keyboard state
	// on all platforms we also use focus/blur events. So we need to make sure here
	// that we avoid redundant keyboard toggling.
	// Minus 100px is needed to make sure that when the internet connection is
	// disabled in android chrome and a small 'No internet connection' text box appears,
	// we do not take it as a sign to open the keyboard
	if (!this.state.isKeyboardOpen && this.props.windowHeight < prevProps.windowHeight - 100) {

• Add onRowMouseDown to <OptionsList here

onRowMouseDown={(e) => {
                    if (!e || !this.textInput.isFocused() || !this.isKeyboardOpen) {
                        return;
                    }
                    
                    e.preventDefault();
                }}

• Add onMouseDown={this.props.onRowMouseDown} to OptionRow in here, then inside OptionRow here, assign the onMouseDown to the this.props.onMouseDown:

onMouseDown={this.props.onMouseDown}

What alternative solutions did you explore? (Optional)

NA

Result

mweb/chrome

Screenrecorder-2023-07-21-15-03-23-121.mp4

android

Screen.Recording.2023-07-21.at.15.21.41.mov

[mollfpr]

Sorry I got a problem with updating the NPM, I'll be posting an update in the morning.

[mollfpr]

@tienifr It seems to be working, but on mWeb/Chrome the keyboard now popping up again like #20636

[tienifr]

original-69D40746-4FA4-4AFA-BDD1-0BDA2A620CFE.mp4

Here's my evidence, It works well by my side, can you please share your video? Thanks

[mollfpr]

@tienifr Could you try it on Android Chrome? It is working fine on iOS Safari.

[tienifr]

Screen_Recording_20230714_165425_Chrome.mp4

@mollfpr Here you are

[mollfpr]

@tienifr Could you attach the diff you use?

[tienifr]

@mollfpr Here you are

In OptionRow.js line 191

                            hoverStyle={this.props.hoverStyle}
+                           onMouseDown={this.props.onMouseDown}

In BaseOptionsList.js line 180

                shouldDisableRowInnerPadding={this.props.shouldDisableRowInnerPadding}
+               onMouseDown={this.props.onRowMouseDown}

In BaseOptionsSelector.js line 341

                listContainerStyles={this.props.listContainerStyles}
                isLoading={!this.props.shouldShowOptions}
+               onRowMouseDown={(e) => {
+                   if (!e || !this.textInput.isFocused()) {
+                       return;
+                   }
+                    e.preventDefault();
+                }}
            />
        );

I also pushed these changes in this branch

[melvin-bot]

📣 It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? 💸

[mollfpr]

@tienifr The issue #20636 arises again with your solution.

mwebchrome.webm

On Android, the keyboard is not pop again on pressing the option.

[tienifr]

@mollfpr I tried some different Android devices and I did not see your problem. Can you help pull the latest main or try one more other device. Thanks.

[mollfpr]

@tienifr Here is the latest main v1.3.43-3.

The step:

1. Open the invite workspace page and make sure that the input is focused and the keyboard is open
2. Press the arrow down button in your Android device to hide the keyboard
3. Press the option select
4. The keyboard shouldn't be pop up again like in the Android app

mWeb/Chrome

mwebchrome.webm

Android

android.webm

[tienifr]

@mollfpr Thanks for pointing that out. The key problem here is Press the arrow down button in your Android device to hide the keyboard. When we do that, the input is still focused but the keyboard is hidden.

I want to add the new logic to detect the keyboard is open or not on BaseOptionsSelector like what we did in PDFView

    componentDidUpdate(prevProps) {
        if (!this.isKeyboardOpen && this.props.windowHeight < prevProps.windowHeight -100) {
            this.isKeyboardOpen=true
        } else if (this.isKeyboardOpen && this.props.windowHeight > prevProps.windowHeight + 100) {
            this.isKeyboardOpen=false
        }
...

onRowMouseDown={(e) => {
                    if (!e || !this.textInput.isFocused() || !this.isKeyboardOpen) {
                        return;
                    }
                    
                    e.preventDefault();
                }}

Result

mweb/chrome

Screenrecorder-2023-07-21-15-03-23-121.mp4

android

Screen.Recording.2023-07-21.at.15.21.41.mov

[mollfpr]

@tienifr Thanks for the update.

Several questions.

• Where is the 100 value come from in !this.isKeyboardOpen && this.props.windowHeight < prevProps.windowHeight -100?
• Why it's working differently in mWeb Chrome?

[tienifr]

@mollfpr I just updated my proposal #22510 (comment) Can you help verify it. Thanks

[melvin-bot]

📣 It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? 💸

[mollfpr]

@tienifr Is there any other way to detect the keyboard open in Chrome? I feel watching the window height is a workaround.

[tienifr]

I did think about this before, but I can't find other better way. In PDFView we're using windowHeight to detect the keyboard is open so I think it's fine @mollfpr

[tienifr]

@mollfpr Does it fit for you? Or do you have any suggestions?

[mollfpr]

@tienifr I couldn't find any other solution too, I guess we can do the same as we already implemented that and it's also not a common issue.

I just tested your code again, on mWeb the focus is not persisted after pressing the row. Is this because of this line?

App/src/pages/workspace/WorkspaceInvitePage.js

Line 227 in 96c765d

shouldFocusOnSelectRow={!Browser.isMobile()}

Even though I enabled the shouldFocusOnSelectRow, the Next button is jumping while the keyboard is open and the keyboard opens after pressing the row.

error.webm

[tienifr]

on mWeb the focus is not persisted after pressing the row

@mollfpr If we're focus on the input but the keyboard is not open (by pressing the down button), we have to blur the input to prevent the keyboard open again as your report

if we enable shouldFocusOnSelectRow, we'll open the keyboard if we're still focus on this input no matter the keyboard is open or not.

the Next button is jumping while the keyboard is open

I can't reproduce your issue if I enable shouldFocusOnSelectRow. Are you checking on the latest main? You can use my branch here https://github.com/tienifr/App/tree/fix/22510

[melvin-bot]

@puneetlath @mollfpr this issue is now 3 weeks old. There is one more week left before this issue breaks WAQ and will need to go internal. What needs to happen to get a PR in review this week? Please create a thread in #expensify-open-source to discuss. Thanks!

[mollfpr]

Sorry for the delay, doesn't have much time left but I'll give an update in the morning.

In summary, I think we can ignore the case where the keyboard is close, and the input still focuses on mWeb Chrome. After all, this issue is regarding the keyboard being close upon selecting the option row.

[melvin-bot]

📣 It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? 💸

[mollfpr]

Sorry for the delay.

Test the proposal from @tienifr, and it does fix this issue. The other case where the keyboard is closed, and the input still focuses is out of the scope of this issue. Let's move forward with the @tienifr solution 🚀

🎀 👀 🎀 C+ reviewed!

[melvin-bot]

Current assignee @puneetlath is eligible for the choreEngineerContributorManagement assigner, not assigning anyone new.

[melvin-bot]

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

[melvin-bot]

@puneetlath @mollfpr this issue is now 4 weeks old and preventing us from maintaining WAQ, can you:

• Decide whether any proposals currently meet our guidelines and can be approved as-is today
• If no proposals meet that standard, please take this issue internal and treat it as one of your highest priorities
• If you have any questions, don't hesitate to start a discussion in #expensify-open-source

Thanks!

[melvin-bot]

Current assignee @mollfpr is eligible for the Internal assigner, not assigning anyone new.

[mollfpr]

Friendly bump @puneetlath on this #22510 (comment)

[melvin-bot]

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

[tienifr]

@puneetlath Can you please assign me to this GH so I can start to implement the PR?

The other case where the keyboard is closed, and the input still focuses is out of the scope of this issue

BTW, I have some confusions about this message ^, it's out of the scope, should we fix this case? @mollfpr

[puneetlath]

Hi guys, sorry for the delay here. I've had second thoughts and I don't feel like this is something we should fix. It feels like we're hacking around how that native platforms themselves work and making our code more complex/brittle to do it. My thinking is that we should actually just close this issue and leave this behavior as-is.

Sorry for the time that was spent getting to this point so far. Please feel free to continue the conversation if you disagree.