Bug: [$500] Keyboard doesn't appear for the "Room Name" field on web/safari

[kbecciv]

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

---

Issue found when executing PR #11587

Action Performed:

1. Go to https://staging.new.expensify.com/
2. Login with expensifail account, for example [email protected]/ Password1
3. Create a Workspace
4. Tap "+"
5. Tap "New Room"

Expected Result:

"Room name" field should be focused and I suppose keyboard should be already on the screen to start typing

Actual Result:

"Room name" filed is focused, but no keyboard on the screen to start typing room name. Additional tap is required to pop up keyboard.

Workaround:

Unknown

Platform:

Where is this issue occurring?

• mWeb/safari

Version Number: 1.2.13.2

Reproducible in staging?: Yes

Reproducible in production?: n/a

Email or phone of affected tester (no customers): any expensifail accounts

Logs: https://stackoverflow.com/c/expensify/questions/4856

Notes/Photos/Videos: Any additional supporting documentation

Bug5773619_11587_mweb_ios.mp4

Expensify/Expensify Issue URL:

Issue reported by: Applause - Internal Team

Slack conversation:

View all open jobs on GitHub

[melvin-bot]

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

[danieldoglas]

ok, this can be external

[melvin-bot]

Triggered auto assignment to @miljakljajic (External), see https://stackoverflow.com/c/expensify/questions/8582 for more details.

[melvin-bot]

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

[melvin-bot]

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

[miljakljajic]

Is there a slack discussion anywhere for this one?

[eVoloshchak]

Is there a slack discussion anywhere for this one?

Couldn't find anything by searching on slack, there's probably none since it was found while testing another issue

[miljakljajic]

Job posted to Upwork.

[jasperhuangg]

We're still waiting for proposals on this one, correct?

[jasperhuangg]

Demoting to Weekly as we're still waiting for proposals on this one.

[miljakljajic]

That's correct, thanks Jasper!

[miljakljajic]

Doubled to $500.

[StefanNemeth]

Safari on iOS is a bit more strict regarding the virtual keyboard than Chrome or other browsers on Android. The keyboard may only open when an input element is focused on a click event. So the solution would be to focus on the click event that occurs when clicking on the plus button (using autoFocus might also work here).

[eVoloshchak]

So the solution would be to focus on the click event that occurs when clicking on the plus button (using autoFocus might also work here).

Thanks for the proposal, this hack would indeed work, but we generally try to avoid such workarounds unless necessary

[eVoloshchak]

I think this might have the same reason as #8292 (comment), which ultimately came down to implementing custom events for the drawer, which would allow us to focus the keyboard after all of the drawer animations are finished.
This change was going to be implemented in #9253, but after that, it was decided to discuss if continuing to use a drawer navigator is a good idea.

Should this also be put on hold?

[StefanNemeth]

So the solution would be to focus on the click event that occurs when clicking on the plus button (using autoFocus might also work here).

Thanks for the proposal, this hack would indeed work, but we generally try to avoid such workarounds unless necessary

I wouldn't really call it a hack. Currently onTransitionEnd triggers the focus, however iOS requires it to be on the click event, which means e.g. the mounted event has to trigger it.

It won't be possible any other way (without being hacky).

[eVoloshchak]

iOS requires it to be on the click event, which means e.g. the mounted event has to trigger it.

You are correct, I suppose that custom events for navigation won't help us, since we would still be calling focus() not from click event.

Let's wait for other proposals

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

[sketchydroide]

closing as duplicated of #10414 more details here and here