[$4000] Android - Edit message - keyboard is dismissed after selecting an emoji @Tushu17

[kbecciv]

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 steps:

1. Send a message in any chat in App
2. Long press the message and tap on Edit message
3. Tap on the emoji picker
4. Select an emoji and observe the keyboard is dismissed

Expected results:

The alphabetical keyboard should not be dismissed after selecting an emoji

Actual Result:

Keyboard doesn't open up after selecting emoji.

Workaround:

Unknown

Platform:

Where is this issue occurring?

• Android

Version Number: 1.1.69.2

Reproducible in staging?: Yes

Reproducible in production?: Yes

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

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

Notes/Photos/Videos: Any additional supporting documentation

Screen_Recording_20220415-030417_New.Expensify.mp4

Upwork URL: https://www.upwork.com/jobs/~01f30fad98ca9b6c69

Issue reported by: @Tushu17

Slack conversation: https://expensify.slack.com/archives/C01GTK53T8Q/p1650039236885699

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~018e351e7d34632075
• Upwork Job ID: 1599837238530191360

[melvin-bot]

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

[melvin-bot]

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

[trjExpensify]

👋 @kbecciv @Tushu17, it took me a second to figure this out based on the steps provided and the issue title. Do you think it's more accurately described as:

Title: Android - Edit message - keyboard is dismissed after selecting an emoji

Action steps:

1. Send a message in any chat in App
2. Long press the message and tap on Edit message
3. Tap on the emoji picker
4. Select an emoji and observe the keyboard is dismissed

Expected results:
The alphabetical keyboard should not be dismissed after selecting an emoji

Let me know and we can update this for clarity.

[melvin-bot]

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

[melvin-bot]

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

[trjExpensify]

Cool, updated. Ready for engineering triage!

[Julesssss]

I can reproduce it, but I think the expected result should be modified to the following:

The alphabetical keyboard should re-open if it was closed when we displayed the emoji picker

Does anyone disagree? It makes more sense to me that we would close the keyboard while the emoji picker is open, then re-open it ONLY if it was open prior to the emoji picker being selected.

[trjExpensify]

Isn't it always open prior when editing? 🤔

[Julesssss]

Not if the user manually closes the keyboard. I do this when writing a long message so i can review the full message in a single screen.

Though rare, I would be annoyed if I finished writing a message, closed the keyboard, added an emoji and then saw the keyboard pop up again. Especially because it's super laggy.

[Tushu17]

Hey @Julesssss, The behaviour is also inconsistent. The keyboard opens after selecting the emoji at composer.

Screen.Recording.2022-06-11.at.1.16.10.AM.mov

.

[Julesssss]

Thanks, @Tushu17.

@trjExpensify this is the case which I believe should be excluded:

screen-20220611-164945.mp4

[trjExpensify]

^^ Ah right yes, but that's not in edit mode is it?

[Julesssss]

That's true. But I still think our solution should revert the keyboard state to the state it was in prior to opening the emoji menu. This handles both the original bug, and the annoying edge-case I pointed out

[Julesssss]

I think the issue should be 'ensure the keyboard state matches the pre-emoji menu state', and I'll list both use cases as tests. That should ensure we attract good proposals.

[trjExpensify]

Okay cool, I see what you're saying. Let's do it. 👍

[parasharrajat]

Checking it now.

[parasharrajat]

I can't reproduce this issue on the simulator but I can on the production app. @ntdiary because you seem interested, feel free to propose a solution.

Note: I am discarding all the old proposals. Please share new proposals in the new template. No hacks, we need a proper solution to solve this issue. Speed of keyboard showing back matters. There should be no delay before keyboard is shown back and after picker is closed. it should feel spontaneous.

[ntdiary]

This issue is no longer reproducible after PR #27340 was merged, because now when the emoji modal opens, the focus will automatically shift from the main composer to the emoji search input, which implements the first point I mentioned before:

1. Re-ensure the composer is blurred when showing the emoji modal.

To be honest, personally I'm not inclined towards the emoji search input auto focusing on mobile, as the effect looks a bit weird. However, if the team thinks it's fine, please feel free to close this issue. 😂

test.mp4

[Julesssss]

Oh god, yeah we definitely shouldn't auto-focus the emoji search. It slows down the interaction time and reduces the available space by showing the soft keyboard.

[trjExpensify]

I think the emoji search is expected to be focused, as it is on web/desktop. If we want to deviate from that, I suggest that's a new issue and a discussion in Slack.

As for this issue on the keyboard being dismissed after selecting an emoji, it seems like we're resolved here. Is that correct?

[Julesssss]

If it's expected on web/desktop (which I agree with), then this is a good example of a place in which all platforms should NOT align.

We currently do this when opening a chat because automatically showing the soft keyboard on mobile is slow and annoying as it covers ~40% of the vertical page height. We shouldn't do this for emoji's either.

[Julesssss]

But I'm happy to raise that elsewhere. And yes, the original issue here is now resolved 🎉

[trjExpensify]

Yeah, I think that's just out of scope on this issue and needs to be taken some place else.

So here, we just need to pay @Tushu17 $250 for the OG bug report.

[trjExpensify]

@Julesssss a good place to start: #27047

[parasharrajat]

I am currently building the app to test it.

[Julesssss]

@Julesssss a good place to start: #27047

Thanks, I'm handling the revert here.

[parasharrajat]

Okay, It seems fixed now on main but it will reproduce again after #28228 is reverted. We should hold on to that issue. It got fixed with #27340 but that is not a permanent solution IMO.

[Julesssss]

Oh of course. Good spot!

[Tushu17]

So here, we just need to pay @Tushu17 $250 for the OG bug report.

Thank you @trjExpensify, offer accepted.

[trjExpensify]

Perfect, paid!

[parasharrajat]

@trjExpensify This should not be closed as we discussed #9252 (comment) here. Can you please reopen?

[trjExpensify]

So what are the next steps and who's doing those?

[Julesssss]

We're back to seeking proposals. Latest comment

[trjExpensify]

This issue is a bit of a spider web, IMO. Should we open a new issue with whatever relevant summary on where we are at, what we don't want to entertain, and then we'll add help wanted and external to that to seek proposals a fresh. At this point, I'm concerned nobody is going to catch up on 300+ comments and a bunch of linked issues to suggest a proposal here.

[Julesssss]

I think that's okay as long as we keep the same bounty

…

On Tue, 3 Oct 2023, 14:28 Tom Rhys Jones, ***@***.***> wrote: This issue is a bit of a spider web, IMO. Should we open a new issue with whatever relevant summary on where we are at, what we don't want to entertain, and then we'll add help wanted and external to that to seek proposals a fresh. At this point, I'm concerned nobody is going to catch up on 300+ comments and a bunch of linked issues to suggest a proposal here. — Reply to this email directly, view it on GitHub <#9252 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACR5JXPWZBFRC6SPECIDUBTX5QHGPAVCNFSM5XNNQKPKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCNZUGQ4TOOJXGU3Q> . You are receiving this because you modified the open/close state.Message ID: ***@***.***>

[trjExpensify]

Yes, we keep the assignees and bounty the same but the issue is summarised with what we will accept/not accept in the expected results and any relevant TL;DR of the history that we landed on there.

[getusha]

Yes, we keep the assignees and bounty the same but the issue is summarised with what we will accept/not accept in the expected results and any relevant TL;DR of the history that we landed on there.

I started investigating this issue and to read and understand what's the ideal proposal and know what kind of proposals posted takes a lot of time this will be very helpful.

[trjExpensify]

So @parasharrajat is that something you will summarise for where we're at this far?

[parasharrajat]

@trjExpensify I think it has been summarized a few times now. Let's create a new issue as you suggested, keeping the same assignees and please add

No hacks, we need a proper solution to solve this issue. The speed of the keyboard showing back matters. There should be no delay before the keyboard is shown back and after the picker is closed. it should feel spontaneous.

in the expected section as well. Please link this issue to the description for reference.