-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[$4000] Android - Edit message - keyboard is dismissed after selecting an emoji @Tushu17 #9252
Comments
Triggered auto assignment to @trjExpensify ( |
@trjExpensify Whoops! This issue is 2 days overdue. Let's get this updated quick! |
👋 @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:
Expected results: Let me know and we can update this for clarity. |
@trjExpensify Uh oh! This issue is overdue by 2 days. Don't forget to update your issues! |
Triggered auto assignment to @Julesssss ( |
Cool, updated. Ready for engineering triage! |
I can reproduce it, but I think the expected result should be modified to the following:
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. |
Isn't it always open prior when editing? 🤔 |
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. |
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. |
Thanks, @Tushu17. @trjExpensify this is the case which I believe should be excluded: screen-20220611-164945.mp4 |
^^ Ah right yes, but that's not in edit mode is it? |
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 |
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. |
Okay cool, I see what you're saying. Let's do it. 👍 |
Checking it now. |
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. |
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:
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 |
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. |
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? |
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. |
But I'm happy to raise that elsewhere. And yes, the original issue here is now resolved 🎉 |
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. |
@Julesssss a good place to start: #27047 |
I am currently building the app to test it. |
Thanks, I'm handling the revert here. |
Oh of course. Good spot! |
Thank you @trjExpensify, offer accepted. |
Perfect, paid! |
@trjExpensify This should not be closed as we discussed #9252 (comment) here. Can you please reopen? |
So what are the next steps and who's doing those? |
We're back to seeking proposals. Latest comment |
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 |
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: ***@***.***>
|
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. |
So @parasharrajat is that something you will summarise for where we're at this far? |
@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
in the expected section as well. Please link this issue to the description for reference. |
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:
Edit message
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?
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
The text was updated successfully, but these errors were encountered: