[HOLD for payment 2023-12-15] [$500] Chat - The Emoji search field is focused when clicking on Modifier keys

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

---

Version Number: 1.3.95.0
Reproducible in staging?: y
Reproducible in production?: y
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: @daveSeife
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1698154419378969

Action Performed:

1. Go to any Chat
2. Blur the main composer(Unfocus the main composer)
3. Click on Modifier keys like 'cmd'. Notice that the composer is not focused
4. Click on the emoji in the composer to open the emoji section. 5. unfocus the emoji search field.
5. Click on Modifier keys like 'cmd'. Notice that the composer is focused

Expected Result:

The Emoji search field is not focused when clicking on Modifier keys

Actual Result:

The Emoji search field is focused when clicking on Modifier keys

Workaround:

Unknown

Platforms:

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

• Android: Native
• Android: mWeb Chrome
• iOS: Native
• iOS: mWeb Safari
• MacOS: Chrome / Safari
• MacOS: Desktop

Screenshots/Videos

t7keyboardFocus.Desktop.1.mp4

t7keyboardFocus.macChrome.1.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~011a4c2fb2e41d1f1c
• Upwork Job ID: 1720501550008877056
• Last Price Increase: 2023-11-17
• Automatic offers:
• dukenv0307 | Contributor | 27820697
• daveSeife | Reporter | 27820699

[melvin-bot]

Triggered auto assignment to @dylanexpensify (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details.

[melvin-bot]

Bug0 Triage Checklist (Main S/O)

• This "bug" occurs on a supported platform (ensure Platforms in OP are ✅)
• This bug is not a duplicate report (check E/App issues and #expensify-bugs)
  • If it is, comment with a link to the original report, close the issue and add any novel details to the original issue instead
• This bug is reproducible using the reproduction steps in the OP. S/O
  • If the reproduction steps are clear and you're unable to reproduce the bug, check with the reporter and QA first, then close the issue.
  • If the reproduction steps aren't clear and you determine the correct steps, please update the OP.
• This issue is filled out as thoroughly and clearly as possible
  • Pay special attention to the title, results, platforms where the bug occurs, and if the bug happens on staging/production.
• I have reviewed and subscribed to the linked Slack conversation to ensure Slack/Github stay in sync

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~011a4c2fb2e41d1f1c

[melvin-bot]

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

[DrLoopFall]

Proposal

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

The Emoji search field is focused when clicking on Modifier keys

What is the root cause of that problem?

We are currently focusing emoji picker's search input whenever a key is pressed,

App/src/components/EmojiPicker/EmojiPickerMenu/index.js

Lines 325 to 327 in aa30ef2

	if (searchInputRef.current && !searchInputRef.current.isFocused()) {
	searchInputRef.current.focus();
	}

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

Only focus the search input if the user presses the keys which would add text to the input.

[dukenv0307]

Proposal

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

The Emoji search field is focused when clicking on Modifier keys

What is the root cause of that problem?

The conditions for autofocusing via keypress for emoji picker here and composer here are not aligned

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

We need to add the missing rules from composer autofocus logic to the emoji picker autofocus logic

For this specific issue, using this rule in here should be enough, but we should consider other rules as well to make it consistent and avoid similar bugs.

// If the key pressed is non-character keys like Enter, Shift, ... do not focus
if (keyBoardEvent.key.length > 1) {
    return;
}

This should also be used:

// If a key is pressed in combination with Meta, Control or Alt do not focus
if (keyBoardEvent.metaKey || keyBoardEvent.ctrlKey || keyBoardEvent.altKey) {
    return;
}

Since many rules can be reused between the composer and the emoji picker (and any other input that requires autofocusing on key press), we can create an util shouldAutoFocusOnKeyPress(event) to wrap the shared logic (some rules are not shared though so we still need to check those few case by case)

What alternative solutions did you explore? (Optional)

NA

[dylanexpensify]

@robertKozik can we review these proposals today, please?

[robertKozik]

@dukenv0307

This should also be used:

// If a key is pressed in combination with Meta, Control or Alt do not focus
if (keyBoardEvent.metaKey || keyBoardEvent.ctrlKey || keyBoardEvent.altKey) {
    return;
}

won't it prevent focus for typing special characters? f.e € is option + 3. I think this should focus both composer and picker as we cannot assume what user wanted to type exactly

[DrLoopFall]

@robertKozik

Also preventing the Control key would break many things that are currently working when the input is not focused, like paste (ctrl+v), select all (ctrl+a), undo (ctrl+z), and others.

I think the best option would be not to focus the input if the user presses only the modifier keys (maybe also keyBoardEvent.metaKey and keyBoardEvent.altKey on non-Mac), something like

if (keyBoardEvent.metaKey || keyBoardEvent.key === 'Control' || keyBoardEvent.key === 'Shift' || keyBoardEvent.key === 'Alt') {
    return;
}

// or

if (keyBoardEvent.metaKey || keyBoardEvent.key.length > 1) {
    return;
}

But this would also focus the input for browser action like ctrl+d (bookmark) or alt+d (focus address bar), to prevent this we can add another event listener without useCapture, but then it would focus for keys with modifier and without browser action like ctrl+alt+a (which won't trigger any action or input), so I think it would be best to prevent focusing on inputs with just modifier keys.

Alternatively, we can manually check for keys like ctrl+v, ctrl+z, and others.

[dukenv0307]

won't it prevent focus for typing special characters? f.e € is option + 3. I think this should focus both composer and picker as we cannot assume what user wanted to type exactly

@robertKozik You're right, we can remove the Option key from the condition since Option key combined with another key will produce text, the rest like metaKey, ctrlKey will still remain. We can do the same check for Option key like the way we do for shift key in emoji picker.

We can fix the issue you mentioned in the main composer as well since it's also happening there

[dylanexpensify]

Thanks for the follow up, @dukenv0307! @robertKozik thoughts?

[melvin-bot]

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

[melvin-bot]

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

[melvin-bot]

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

[dylanexpensify]

Mind giving next steps here @robertKozik?

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

@dylanexpensify, @robertKozik 6 days overdue. This is scarier than being forced to listen to Vogon poetry!

[dylanexpensify]

bump @robertKozik

[dukenv0307]

@robertKozik The PR is ready for review.

[dylanexpensify]

bump @robertKozik!

[robertKozik]

I see it got already merged @dylanexpensify

[melvin-bot]

⚠️ Looks like this issue was linked to a Deploy Blocker here

If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.

If a regression has occurred and you are the assigned CM follow the instructions here.

If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future.

[melvin-bot]

⚠️ Looks like this issue was linked to a Deploy Blocker here

If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.

If a regression has occurred and you are the assigned CM follow the instructions here.

If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future.

[melvin-bot]

Reviewing label has been removed, please complete the "BugZero Checklist".

[melvin-bot]

The solution for this issue has been 🚀 deployed to production 🚀 in version 1.4.9-5 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:

• Consistent key press focus logic between composer and emoji picker #31899

If no regressions arise, payment will be issued on 2023-12-15. 🎊

After the hold period is over and BZ checklist items are completed, please complete any of the applicable payments for this issue, and check them off once done.

• External issue reporter
• Contributor that fixed the issue
• Contributor+ that helped on the issue and/or PR

For reference, here are some details about the assignees on this issue:

• @robertKozik does not require payment (Contractor)
• @dukenv0307 requires payment automatic offer (Contributor)
• @daveSeife requires payment automatic offer (Reporter)

[melvin-bot]

BugZero Checklist: The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed:

• [@robertKozik] The PR that introduced the bug has been identified. Link to the PR:
• [@robertKozik] The offending PR has been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake. Link to comment:
• [@robertKozik] A discussion in #expensify-bugs has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner. Link to discussion:
• [@robertKozik] Determine if we should create a regression test for this bug.
• [@robertKozik] If we decide to create a regression test for the bug, please propose the regression test steps to ensure the same bug will not reach production again.
• [@dylanexpensify] Link the GH issue for creating/updating the regression test once above steps have been agreed upon:

[dylanexpensify]

payment upcoming! 🤑

[melvin-bot]

@marcaaron, @dylanexpensify, @robertKozik, @dukenv0307 Whoops! This issue is 2 days overdue. Let's get this updated quick!

[robertKozik]

• [@robertKozik] The PR that introduced the bug has been identified. Link to the PR: It's not a regression introduced but any particular PR - rather inconsistency in handling focus of the input
• [@robertKozik] The offending PR has been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake. Link to comment: N/A
• [@robertKozik] A discussion in #expensify-bugs has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner. Link to discussion: N/A
• [@robertKozik] Determine if we should create a regression test for this bug. I don't think we need new regression test here
• [@robertKozik] If we decide to create a regression test for the bug, please propose the regression test steps to ensure the same bug will not reach production again. N/A

[dylanexpensify]

paying out today!

[dylanexpensify]

Payment summary:

• Reporter: @daveSeife $50
• Contributor: @dukenv0307 $500
• Contributor+ @robertKozik

Please apply!

[dylanexpensify]

done!