[HOLD App#11795] [$500] Pressing enter takes the focus to Add a personal message field on Android - reported by @thesahindia

[mvtglobally]

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. Open :expensify: at mobile browser on Android
2. Go to settings > workspace > manage members > invite
3. Press enter on keyboard

Alternative Flow

1. Open :expensify: at mobile browser
2. Go to settings > workspace > manage members > invite
3. Tap on Add a personal message field and press enter

Expected Result:

• Pressing enter should not change the focus to the personal message field
• Pressing enter a first time should select the first contact
• Pressing enter another time should select the next contact in the list

Screen.Recording.2022-08-08.at.11.44.43.AM.mov

Actual Result:

On pressing enter the Add a personal message field gets focused

The user can't go to the next line and pressing enter selects the contacts

Workaround:

unknown

Platform:

Where is this issue occurring?

• Mobile Web (Android)
• Android

Make sure this works same on iOS too and matches desktop/browser behaviour.

Version Number: 1.1.85-8
Reproducible in staging?: Y
Reproducible in production?: Y
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos: Any additional supporting documentation

Screenrecording_20220710_012126.mp4

potentially related to https://expensify.slack.com/archives/C01GTK53T8Q/p1657397089778049

Expensify/Expensify Issue URL:
Issue reported by: @thesahindia
Slack conversation: https://expensify.slack.com/archives/C01GTK53T8Q/p1657396762843809

View all open jobs on GitHub

[melvin-bot]

Triggered auto assignment to @MitchExpensify (AutoAssignerTriage), see https://stackoverflow.com/c/expensify/questions/4749 for more details.

[MitchExpensify]

I am unable to reproduce this on iOS

[thesahindia]

I am unable to reproduce this on iOS

Only reproducible at android mobile browsers

[MitchExpensify]

Asked in Slack for help with reproduction - https://expensify.slack.com/archives/C01GTK53T8Q/p1659456631390199?thread_ts=1657396762.843809&cid=C01GTK53T8Q

[MitchExpensify]

@rushatgabhane reproduced on v1.1.86-5, Chrome, Android 12

This is odd behavior, labelling Engineering accordingly

[melvin-bot]

Triggered auto assignment to @Justicea83 (Engineering), see https://stackoverflow.com/c/expensify/questions/4319 for more details.

[Justicea83]

this can be external

[melvin-bot]

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

[MitchExpensify]

Upwork Job

[melvin-bot]

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

[melvin-bot]

Triggered auto assignment to @aldo-expensify (Exported), see https://stackoverflow.com/c/expensify/questions/7972 for more details.

[railway17]

Proposal

I could replicate the issue in only real devices, not simulators.

Actually, this is an exceptional case in Android devices, which we can reproduce even though we test with 2 input boxes in an empty page.
So, we can resolve this issue by adding returnKeyType props in the OptionsSelector like this.

const textInput = (
            <TextInput
                ref={el => this.textInput = el}
                value={this.props.value}
                label={this.props.textInputLabel}
                onChangeText={(text) => {
                    if (this.props.shouldFocusOnSelectRow) {
                        this.textInput.setNativeProps({selection: null});
                    }
                    this.props.onChangeText(text);
                }}
                placeholder={this.props.placeholderText || this.props.translate('optionsSelector.nameEmailOrPhoneNumber')}
                onBlur={(e) => {
                    if (!this.props.shouldFocusOnSelectRow) {
                        return;
                    }
                    this.relatedTarget = e.relatedTarget;
                }}
                selectTextOnFocus
+               returnKeyType="done"
                blurOnSubmit={Boolean(this.state.allOptions.length)}
            />

It will resolve this issue.

[parasharrajat]

@railway17's proposal can be improved. it is missing proper explanation and not easy to understand. (Please try to make it easier for a reviewer to understand your proposal). The easier it is to understand, the better odds for you.

Could you please add the following details to it?

1. What behavior are you proposing?
2. Explain how you will achieve it in steps and then use code to support your explanation.
3. There are different scenarios involved on that page. Explain, how is your proposal supporting those?
   for example, if the first option in the list is already selected, what will happen when pressing enter? etc.

What do you mean by selected from ahead one by one?

[mountiny]

@parasharrajat @shawnborton @MitchExpensify @aldo-expensify I am unsure if we should just proceed with this one on its own. Seems like the solution to it is quite involved and we have other similar forms/lists in the App which should have the same behaviour and I dont think we should only focus on this one solely.

The solution/behaviour should be same for all instances of this input form. At the same time, this feels like low ROI at the moment with out attention to better performance of the app.

I think it would be better to put this on HOLD and have some predesign about how this input form should behave across the platforms, clearly define all the scenarios and how they should be handled (similarly as we are doing with the navigation now), otherwise we will have many of similar issues like this where we will be trying to tweak the behaviour slightly depending on who the CME is 😄 Thoughts?

[melvin-bot]

Looks like something related to react-navigation may have been mentioned in this issue discussion.

As a reminder, please make sure that all proposals are not workarounds and that any and all attempt to fix the issue holistically have been made before proceeding with a solution. Proposals to change our DeprecatedCustomActions.js files should not be accepted.

Feel free to drop a note in #expensify-open-source with any questions.

[shawnborton]

I like the idea of putting this on HOLD while we design a better solution.

[MitchExpensify]

Would leading that pre-design typically fall on the CM or CME? This is the first time I've run into a case like this as CM

[shawnborton]

I think we'd want to put this back on our internal design team to come up with a better solution, and probably just close this one out altogether?

[aldo-expensify]

I think we'd want to put this back on our internal design team to come up with a better solution, and probably just close this one out altogether?

Sounds good to me! and totally agree with what @mountiny said here: #10181 (comment)

[MitchExpensify]

I think we'd want to put this back on our internal design team to come up with a better solution, and probably just close this one out altogether?

Cool! I'm tempted to pay out half price ($250) to C+ and the reporter of the issue for their work on this. What do you reckon @michaelhaxhiu ? (CM buddy check)

[mountiny]

Cool! I'm tempted to pay out half price ($250) to C+ and the reporter of the issue for their work on this. What do you reckon @michaelhaxhiu ? (CM buddy check)

I agree with paying that out and I dont think either of us necessarily needs to lead the predesign we should just make sure this does not fall through the cracks and it gets done!

[mountiny]

Created a planning issue for this here #11795 so we dont forget about it. Feel free to subscribe to it or take it on if you want to lead this sooner than later!

[michaelhaxhiu]

@MitchExpensify Let's take the pricing question to the internal #contributor-plus channel and discuss there. It would be good to keep track of precedent here in case similar situations arise in the future.

[MitchExpensify]

@MitchExpensify Let's take the pricing question to the internal #contributor-plus channel and discuss there. It would be good to keep track of precedent here in case similar situations arise in the future.

Asked here

[mountiny]

Put this on hold as mentioned before

[tjferriss]

Following instructions for the weekly update chore:

@mountiny this is one of the oldest issues in the /App repo. To help us clear out the large backlog of bugs, can you:

• Decide whether any proposals currently meet our guidelines and can be approved as-is
• For any that can't, 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 #bug-zero

I recognize this issue is on hold so maybe the above is irrelevant, but once it's not on hold do you expect we should take this internal given the issue's age?

[mountiny]

Thanks for the ping, in this particular case I will go ahead and close the issue. My reasons are:

• this is not strictly bug, but it can be considered as feature request.
• this is not blocking users from using the app
• this influences only Android
• we will fix this and similar issues related to option list selection in this issue [Tracker] Selection List Refactor #11795

[parasharrajat]

@MitchExpensify Can you please look into the C+ payment #10181 (comment)

[MitchExpensify]

Hey @parasharrajat, apologies for the delay (Thanksgiving break then I was unwell)

Invite sent to new upwork job

[parasharrajat]

@MitchExpensify Could you please pay this off?

[MitchExpensify]

@parasharrajat Done! Thanks for the bump