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

[melvin-bot[bot]]

Triggered auto assignment to @CortneyOfstad (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.

[lanitochka17]

@CortneyOfstad FYI I haven't added the External label as I wasn't 100% sure about this issue. Please take a look and add the label if you agree it's a bug and can be handled by external contributors

[lanitochka17]

We think that this bug might be related to #vip-vsp

[melvin-bot[bot]]

@CortneyOfstad Eep! 4 days overdue now. Issues have feelings too...

[CortneyOfstad]

Sorry, was OoO!

Was able to recreate, so going to get eyes on this!

[melvin-bot[bot]]

Job added to Upwork: https://www.upwork.com/jobs/~0174c82b024da104ac

[melvin-bot[bot]]

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

[dominictb]

Proposal

Please re-state the problem that we are trying to solve in this issue.

There're 2 problems:

1. Keyboard does not close when users open popover from three dot

https://github.com/Expensify/App/assets/165644294/5463b3a0-fad6-47f5-bc50-d2cea010e495

2. Keyboard does not close when users open action menu (the original issue)

What is the root cause of that problem?

1. We're getting the active input by this function

https://github.com/Expensify/App/blob/0c20881a308244867119efa6196481b65bb81274/src/libs/ComposerFocusManager.ts#L37-L39

but in web platform, we use the div with contentEditable to present the input

-> we can't get the active input -> the logic to blur input here is not triggered

2. To trigger blur input, we need to enable shouldEnableNewFocusManagement in

https://github.com/Expensify/App/blob/0c20881a308244867119efa6196481b65bb81274/src/components/Modal/BaseModal.tsx#L69-L71

but we did not enable it in PopoverWithMeasuredContent

What changes do you think we should make in order to solve the problem?

1. getActiveInput is implemented for both native and web platform, but it's not the same as this comment so we can separate this function in 2 file index.ts and index.native.ts

For native platform, we can keep using currentlyFocusedInput For web/desktop platform, we can use document.activeElement

    const activeElement = document.activeElement
    if(activeElement?.getAttribute('contentEditable') || activeElement?.tagName === 'INPUT'){
        return activeElement
    }

2. Enable shouldEnableNewFocusManagement in PopoverWithMeasuredContent

What alternative solutions did you explore? (Optional)

Use ReportActionComposeFocusManager.composerRef.blur() in

https://github.com/Expensify/App/blob/5e6527613d0f234fcb22507b878697a2bec356c5/src/pages/home/report/ReportActionItem.tsx#L346

Result

https://github.com/Expensify/App/assets/165644294/6450ad67-5890-4551-8741-751b0587346a

[muttmuure]

This is not a #newdot-quality bug - the feature is not unreliable, slow or performing redundant or unexpected API calls, it just doesn't work as designed

[CortneyOfstad]

Thanks for the clarification @muttmuure!

[CortneyOfstad]

@rojiphil there is a proposal here for review 👍

[melvin-bot[bot]]

@rojiphil, @CortneyOfstad Eep! 4 days overdue now. Issues have feelings too...

[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? 💸

[CortneyOfstad]

@rojiphil any updates on the reviews? Please have these completed by EOD.

[melvin-bot[bot]]

@rojiphil @CortneyOfstad this issue was created 2 weeks ago. Are we close to approving a proposal? If not, what's blocking us from getting this issue assigned? Don't hesitate to create a thread in #expensify-open-source to align faster in real time. Thanks!

[melvin-bot[bot]]

@rojiphil, @CortneyOfstad Still overdue 6 days?! Let's take care of this!

[rojiphil]

@dominictb Thanks for the proposal.

getActiveInput is implemented for both native and web platform, but it's not the same as this comment so we can separate this function in 2 file index.ts and index.native.ts

I am not sure if I understand why we need to separate getActiveInput into two files. Especially since the keyboard gets closed on launching emoji picker as shown below even without this change. Can you please share more details on this?

https://github.com/Expensify/App/assets/3004659/58095810-5c07-4749-88fd-72399ee8524b

[dominictb]

There're 2 reasons to separate this function into 2 files

1. As we mentioned in

https://github.com/Expensify/App/blob/0c20881a308244867119efa6196481b65bb81274/src/libs/ComposerFocusManager.ts#L35

currentlyFocusedField is used for web/desktop, and currentlyFocusedInput for native platform.

2. For web platform, we're using the div tag to render the input so TextInput.State.currentlyFocusedField() won't work. That why I decide to use another way to detect active editable element (input or editable div)

Can you reproduce the first bug I mentioned in my proposal?

Keyboard does not close when users open popover from three dot

[dominictb]

@rojiphil ^

[melvin-bot[bot]]

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

[dominictb]

Hi @rojiphil, Can you review my proposal above ^? Thanks

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

Can you review my proposal above ^? Thanks

@dominictb Sorry for the delay here. I will review your comments and provide an update sometime tomorrow my day.

[rojiphil]

Can you reproduce the first bug I mentioned in my proposal?

Keyboard does not close when users open popover from three dot

I could not reproduce this. I think there is a change in the UI design and the 3dot menu does not exist anymore.

[rojiphil]

Regarding separating getActiveInput into two files, I may be missing something here. If you notice in the video below for iOS mWeb, the issue does not occur with eMoji picker but issue occurs for action menu. Why this difference?

https://github.com/Expensify/App/assets/3004659/93837ab3-6ede-4876-9b84-fbe6f93a58f3

[rojiphil]

Also, why does the keyboard hide on Android mWeb whereas keyboard does not hide on iOS mWeb?

https://github.com/Expensify/App/assets/3004659/d0b9817d-e34c-48d5-94fb-dac31d0c10da

[dominictb]

@rojiphil I think it's the platform problem. On iOS, I can long press at any unresponsive place and the keyboard is not hidden. But on android it's hidden.

After applying 2 updates as mentioned in my proposal, it works well. I believe it's the reason to add shouldEnableNewFocusManagement to blur the input.

https://github.com/Expensify/App/blob/39463bdccefd9017b3f4beea889e57e58ad5644e/src/libs/ComposerFocusManager.ts#L110

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

@rojiphil, @CortneyOfstad Eep! 4 days overdue now. Issues have feelings too...

[melvin-bot[bot]]

@rojiphil @CortneyOfstad this issue is now 4 weeks old, please consider:

• Finding a contributor to fix the bug
• Closing the issue if BZ has been unable to add the issue to a VIP or Wave project
• If you have any questions, don't hesitate to start a discussion in #expensify-open-source

Thanks!

[CortneyOfstad]

@rojiphil any additional feedback on the comment here?

[melvin-bot[bot]]

@rojiphil, @CortneyOfstad Still overdue 6 days?! Let's take care of this!

[rojiphil]

I think it's the platform problem. On iOS, I can long press at any unresponsive place and the keyboard is not hidden. But on android it's hidden.

Hmm… Ok. Looks like an android specific issue and may be unrelated to this issue. Let us revisit this a little later.

[rojiphil]

After applying 2 updates as mentioned in my proposal, it works well. I believe it's the reason to add shouldEnableNewFocusManagement to blur the input.

@dominictb I am still curious to know about my comment here on why the eMoji picker works fine without the proposed changes as per your proposal. Can you please investigate on this?

[melvin-bot[bot]]

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

[CortneyOfstad]

@dominictb any update on the comment here?

[dominictb]

will give the feedback in a few hours

[dominictb]

@rojiphil Ah, when you press(single click) on mweb, the keyboard is hidden automatically. But it didn't work in case of long press as I said here

[rojiphil]

After applying 2 updates as mentioned in my proposal, it works well. I believe it's the reason to add shouldEnableNewFocusManagement to blur the input.

@dominictb I am still curious to know about my comment here on why the eMoji picker works fine without the proposed changes as per your proposal. Can you please investigate on this?

@dominictb I am particularly interested to know this. Can you please update on 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? 💸

[melvin-bot[bot]]

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

[dominictb]

@rojiphil I already explained in here. What points do you want me to elaborate?

[rojiphil]

-> we can't get the active input -> the logic to blur input here is not triggered

@dominictb I am not thoroughly convinced yet of the proposed solution. But maybe I am missing something. Anyway, as I understand, not triggering the blur of the composer is the root cause of this issue. If so, would it not be simpler to blur the composer if it is focused when we show popover here?

[dominictb]

@rojiphil Yes we can do that, but I think we already had the logic to do that in

https://github.com/Expensify/App/blob/39463bdccefd9017b3f4beea889e57e58ad5644e/src/libs/ComposerFocusManager.ts#L110

-> we need to fix the bug at this place instead of making the workaround

[rojiphil]

Yes we can do that, but I think we already had the logic to do that

we need to fix the bug at this place instead of making the workaround

@dominictb I think the new logic was originally added for emoji picker keyboard issue to ensure that the keyboard focus comes back on dismissing the emoji modal. However, the logic for bringing the focus back to composer for ReportActionContextMenu is managed by ReportActionComposeFocusManager as mentioned here. So, why is it a workaround to make use of ReportActionComposeFocusManager for blurring the composer?

[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? 💸

[dominictb]

@rojiphil You mean using ReportActionComposeFocusManager.composerRef.blur() in

https://github.com/Expensify/App/blob/5e6527613d0f234fcb22507b878697a2bec356c5/src/pages/home/report/ReportActionItem.tsx#L346

,right?

[wildan-m]

@rojiphil Is the original issue not reproducible? The remaining issue is with long-pressing, right?

[wildan-m]

Proposal

Please re-state the problem that we are trying to solve in this issue.

mWeb/Safari - Chat - Keyboard does not close when action menu opens

The original issue is not reproducible due to changes in the three dots UI, but a similar issue occurs when long pressing the reportActionItem.

What is the root cause of that problem?

In safari IOS, when we long pressing component, the keyboard will not automatically hide and we only intentionally blur the input focus in OptionRowLHN secondaryInteraction event

https://github.com/Expensify/App/blob/8e79c59615feb7de82e4aaa42d8b2297542f5b3b/src/components/LHNOptionsList/OptionRowLHN.tsx#L167-L170

What changes do you think we should make in order to solve the problem?

Move this code: https://github.com/Expensify/App/blob/8e79c59615feb7de82e4aaa42d8b2297542f5b3b/src/components/LHNOptionsList/OptionRowLHN.tsx#L167-L170

To the method that calls the popOver: showPopover, showContextMenuForReport, showPopoverMenu e.g.

src/components/ShowContextMenuContext.ts

function showContextMenuForReport(
    event: GestureResponderEvent | MouseEvent,
    anchor: ContextMenuAnchor,
    reportID: string,
    action: OnyxEntry<ReportAction>,
    checkIfContextMenuActive: () => void,
    isArchivedRoom = false,
) {
    if (!DeviceCapabilities.canUseTouchScreen()) {
        return;
    }

    // Ensure that we blur the composer when opening context menu, so that only one component is focused at a time
    if (DomUtils.getActiveElement()) {
        (DomUtils.getActiveElement() as HTMLElement | null)?.blur();
    }

Branch for this solution.

What alternative solutions did you explore? (Optional)

When onSecondaryInteraction or onLongPress show a popOver, add this code:

 if (DomUtils.getActiveElement()) {
                                (DomUtils.getActiveElement() as HTMLElement | null)?.blur();
                            }

For instance:

                        onSecondaryInteraction={(event) => {
                            // Ensure that we blur the composer when opening context menu, so that only one component is focused at a time
                            if (DomUtils.getActiveElement()) {
                                (DomUtils.getActiveElement() as HTMLElement | null)?.blur();
                            }

                            showPopover(event);
                        }}

or that can also be placed in showContextMenu(

[rojiphil]

@wildan-m Thanks for your proposal but I do not see the approach of your proposed solution anyway different than what's been discussed here.