[$250] mWeb/Safari - Chat - Keyboard does not close when action menu opens

[lanitochka17]

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

---

Version Number: 1.4.85-6 Reproducible in staging?: Y Reproducible in production?: Y If this was caught during regression testing, add the test name, ID and link from TestRail: N/A Email or phone of affected tester (no customers): gibethlehem+3gmail.com Issue reported by: Applause - Internal Team

Action Performed:

1. Go to any chat
2. Click on the composer to bring the keyboard (if its not already open)
3. While the keyboard is open long press on a message to bring the action menu

Expected Result:

The keyboard closes when the action menu is opened

Actual Result:

The keyboard stays open when the action menu is opened

Workaround:

Unknown

Platforms:

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

• [ ] Android: Native
• [ ] Android: mWeb Chrome
• [ ] iOS: Native
• [x] iOS: mWeb Safari
• [ ] MacOS: Chrome / Safari
• [ ] MacOS: Desktop

Screenshots/Videos

Add any screenshot/video evidence

https://github.com/Expensify/App/assets/78819774/2497443c-14a8-4c30-86c0-f96de3c46c55

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~0174c82b024da104ac
• Upwork Job ID: 1805674432646033914
• Last Price Increase: 2024-08-13
• Automatic offers:
• rojiphil | Reviewer | 103557667
• dominictb | Contributor | 103557669

Issue Owner

Current Issue Owner: @rojiphil

[rojiphil]

You mean using ReportActionComposeFocusManager.composerRef.blur() in

@dominictb Yes. Something like that but a helper called blur could help there.

[wildan-m]

@rojiphil, my proposal is a sample implementation of the solution mentioned in this comment. Has this solution already been officially proposed?

[wildan-m]

@rojiphil I've also mentioned existing similar pattern and suggest to move it to the inner method

[melvin-bot[bot]]

Triggered auto assignment to @puneetlath (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

[CortneyOfstad]

Didn't mean to remove the bug label! Sorry Puneet!

[dominictb]

Yes. Something like that but a helper called blur could help there.

@rojiphil Thanks for your suggestion. I added it to alternative solution.

[melvin-bot[bot]]

@rojiphil, @CortneyOfstad Huh... This is 4 days overdue. Who can take care of this?

[melvin-bot[bot]]

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

[rojiphil]

As the logic for bringing the focus back to composer for ReportActionContextMenu is managed by ReportActionComposeFocusManager as mentioned here, using ReportActionComposeFocusManager to blur makes sense to me. @dominictb proposal with the alternate solution LGTM. 🎀👀🎀 C+ reviewed

[melvin-bot[bot]]

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

[wildan-m]

@rojiphil @cead22 why limit the input to ReportActionComposeFocusManager.composerRef, when we should make the solution generic to any input field? (DomUtils.getActiveElement() as HTMLElement | null)?.blur()

[dominictb]

@cead22 Can you help review my proposal? Thanks

[rojiphil]

Why limit the input to ReportActionComposeFocusManager.composerRef, when we should make the solution generic to any input field?

@wildan-m Why do you think we need to make the solution generic to any input field? Making the solution generic could lead to possible regressions where the input field focus needs to be retained post context menu handling.

And even if we have to make the solution generic, @dominictb primary solution makes more sense than yours. Focus management has been a tricky issue for a long time. So, why unnecessarily disturb the existing working system and invite possible regressions when ReportActionComposeFocusManager is already there?

Alternatively, if the idea is to redesign the focus management, then it would be better to do away with ReportActionComposeFocusManager. But, I do not think that is the scope and intent of this issue.

@cead22 can weigh in and conclude on the way ahead.

[wildan-m]

Making the solution generic could lead to possible regressions where the input field focus needs to be retained post context menu handling.

@rojiphil do you have reproducible steps to show that potential regression? I think it's expected to blur the focus from any element when new pop up appeared.

FYI, the selected proposal will not work for editing the message if it's not the main composer. A similar issue will arise when there is active text input and a component with a context menu on the same screen.

[wildan-m]

the selected proposal will not work for editing the message if it's not the main composer.

https://github.com/user-attachments/assets/c6627ef6-cc96-45b5-9b79-e5217e849e5f

[rojiphil]

the selected proposal will not work for editing the message if it's not the main composer.

@wildan-m Yes. That’s why I think ReportActionComposeFocusManager should be used here as that was designed to handle the blur and focus of edit composer and main composer. If this is not working as intended, some regression has caused this. But, this can be addressed in the PR stage.

[cead22]

Correct me if I misunderstood

• @dominictb main proposal (ie, not the alternative) wouldn't solve the issue for the edit composer
• @dominictb alternative proposal solves it for the main composer and the edit composer
• It's possible that that proposal doesn't solve every case
• We could build a generic solution to try to handle every case automatically
• @wildan-m proposal would solve the issue on the edit composer, the main composer, and potentially other cases. That said, we haven't done a deep dive to see what those other cases would be
• @wildan-m proposal has the risk of breaking other places, due to the generic nature of the solution

If that's the case, I think @rojiphil 's concern about breaking other places of the app is valid, specially if we've had recurring issues with focus/blur

[rojiphil]

I think @rojiphil 's concern about breaking other places of the app is valid, specially if we've had recurring issues with focus/blur

@cead22 There are two main approaches here.

1. A generic solution to blur any input field.
2. A specific solution to blur edit composer and main composer.

The generic solution has the risk of breaking other places as we do not know if the focus is expected to remain in the input field after the context menu is dismissed. @dominictb main solution and @wildan-m proposal are both generic and has this risk. Whereas the specific solution via ReportActionComposeFocusManager deals exclusively with blur and focus of edit composer and main composer thereby avoiding the risk of breaking other places in the app. @dominictb alternate solution is to use this approach.

[wildan-m]

@dominictb alternative proposal solves it for the main composer and the edit composer

@cead22 no it is not working for edit

[wildan-m]

do you have reproducible steps to show that potential regression? I think it's expected to blur the focus from any element when new pop up appeared.

@rojiphil you haven't answered all of my question

@wildan-m proposal has the risk of breaking other places, due to the generic nature of the solution my solution adopted

@cead22 my solution come from the existing solution for other case. I don't see any issue from the implementation

[rojiphil]

do you have reproducible steps to show that potential regression? I think it's expected to blur the focus from any element when new pop up appeared.

@rojiphil you haven't answered all of my question

@wildan-m I have already answered your question with the following.

Why do you think we need to make the solution generic to any input field? Making the solution generic could lead to possible regressions where the input field focus needs to be retained post context menu handling.

And even if we have to make the solution generic, @dominictb primary solution makes more sense than yours. Focus management has been a tricky issue for a long time. So, why unnecessarily disturb the existing working system and invite possible regressions when ReportActionComposeFocusManager is already there?

Alternatively, if the idea is to redesign the focus management, then it would be better to do away with ReportActionComposeFocusManager. But, I do not think that is the scope and intent of this issue.

Yes. That’s why I think ReportActionComposeFocusManager should be used here as that was designed to handle the blur and focus of edit composer and main composer. If this is not working as intended, some regression has caused this. But, this can be addressed in the PR stage.

And you already pointed out the regression related to edit composer. Shouldn't the edit composer retain the focus once the context menu action is handled? Isn't ReportActionComposeFocusManager designed to manage the blur and focus of edit composer and main composer? If so, shouldn't ReportActionComposeFocusManager be used to fix this issue? And if at all we want to go with the generic approach, why is your proposal better than the main solution of @dominictb? Can you please address these questions first and we can take this further from there?

[wildan-m]

@rojiphil @cead22 is there a case where we need to keep the previous focus input when a contextMenu shown?

my solution advantage is already described here.

@wildan-m proposal would solve the issue on the edit composer, the main composer, and potentially other cases.

[rojiphil]

@dominictb alternative proposal solves it for the main composer and the edit composer

@cead22 no it is not working for edit

This is already addressed here

[rojiphil]

@cead22 So, based on this comment here, the first decision to make is a) Generic solution or b) Specific solution?

If the specific solution approach is chosen, then @dominic’s alternative approach of using ReportActionComposeFocusManager is good enough.

And if it is fine to blur any input field, the generic solution approach can be chosen. Here both @dominictb main solution and @wildan-m solution would fix the issue (i.e. both main composer and edit composer would work). @wildan-m solution seems like a hack, although the same pattern is used elsewhere. Whereas @dominictb main solution seems neater as that is a new pattern introduced elsewhere recently for focus management. But as bringing back the composer focus is managed by ReportActionComposeFocusManager, we can use the new focus management for only blurring purposes.

This kindof summarizes the entire discussion here. What’s your choice?

[cead22]

And if it is fine to blur any input field,

How many places in the app would be affected?

I ask because if there's many, then maybe this is a larger product discussion, not to mention the PR will need to test every possible place that could be affected

[rojiphil]

And if it is fine to blur any input field,

How many places in the app would be affected?

I ask because if there's many, then maybe this is a larger product discussion, not to mention the PR will need to test every possible place that could be affected

@cead22 Well! I think that’s difficult to determine as the proposed generic approach is using document.activeElement which could be any active element (including the new ones added in the future) in the DOM. That seems pretty scary to me though.

[wildan-m]

This is about defining the expected default behavior for context menus. When a context menu is displayed, which approach should we take?

(1) Should we blur the input by default and add specific conditional checks to retain focus only when necessary? (2) Or should we avoid blurring any input by default, except when specific input fields focused?

[cead22]

@rojiphil any thoughts on that last message from @wildan-m ^?

Full disclosure, I'm leaning @dominictb 's more straightforward solution

[melvin-bot[bot]]

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

[melvin-bot[bot]]

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

[rojiphil]

This is about defining the expected default behavior for context menus. When a context menu is displayed, which approach should we take?

any thoughts on that last message from @wildan-m ^

Sorry I missed this. This issue is specifically to do with blur/focus of the composer and we can keep it limited to this especially since there is an existing pattern around this. While the default behavior for context menus during display is an interesting topic for discussion, it seems like a project itself with a need for a wider consensus to apply in the entire project. You may want to initiate a separate discussion thread on Slack and take it from there.

[melvin-bot[bot]]

📣 @rojiphil 🎉 An offer has been automatically sent to your Upwork account for the Reviewer role 🎉 Thanks for contributing to the Expensify app!

Offer link Upwork job

[melvin-bot[bot]]

📣 @dominictb 🎉 An offer has been automatically sent to your Upwork account for the Contributor role 🎉 Thanks for contributing to the Expensify app!

Offer link Upwork job Please accept the offer and leave a comment on the Github issue letting us know when we can expect a PR to be ready for review 🧑‍💻 Keep in mind: Code of Conduct | Contributing 📖

[cead22]

I agree, so I assigned @dominictb

[melvin-bot[bot]]

@cead22, @rojiphil, @CortneyOfstad, @dominictb Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!

[dominictb]

Working on the PR. It should be ready by today.

[CortneyOfstad]

@dominictb any update on the PR based on the last comment here?

[melvin-bot[bot]]

This issue has not been updated in over 15 days. @cead22, @rojiphil, @CortneyOfstad, @dominictb eroding to Monthly issue.

P.S. Is everyone reading this sure this is really a near-term priority? Be brave: if you disagree, go ahead and close it out. If someone disagrees, they'll reopen it, and if they don't: one less thing to do!

[dominictb]

@CortneyOfstad I have resolved the conflicts. Waiting for @rojiphil final review