Skip to content
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

[HOLD for newdot C+ payment] [$1000] Web - Emoji Reaction - Reaction emoji is highlighted twice when using Tab key #15796

Closed
1 of 6 tasks
kbecciv opened this issue Mar 9, 2023 · 97 comments
Assignees
Labels
Awaiting Payment Auto-added when associated PR is deployed to production Bug Something is broken. Auto assigns a BugZero manager. External Added to denote the issue can be worked on by a contributor Weekly KSv2

Comments

@kbecciv
Copy link

kbecciv commented Mar 9, 2023

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

  1. Go to staging.new.expensify.com
  2. Login with any account
  3. Open a chat with user B
  4. Send a message
  5. Hover over Add Reaction option and select one
  6. Start using Tab key

Expected Result:

Reaction emoji is highlighted once when using Tab key

Actual Result:

Reaction emoji is highlighted twice when using Tab key

Workaround:

Unknown

Platforms:

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

  • Android / native
  • Android / Chrome
  • iOS / native
  • iOS / Safari
  • MacOS / Chrome / Safari
  • MacOS / Desktop

Version Number: 1.2.81.0

Reproducible in staging?: Yes

Reproducible in production?: No

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

Notes/Photos/Videos: Any additional supporting documentation

Recording.2291.mp4

Expensify/Expensify Issue URL:

Issue reported by: Applause - Internal Team

Slack conversation:

View all open jobs on GitHub

Upwork Automation - Do Not Edit
  • Upwork Job URL: https://www.upwork.com/jobs/~010d30323d77b01052
  • Upwork Job ID: 1634009246856626176
  • Last Price Increase: 2023-03-10
@kbecciv kbecciv added Daily KSv2 Bug Something is broken. Auto assigns a BugZero manager. labels Mar 9, 2023
@melvin-bot melvin-bot bot locked and limited conversation to collaborators Mar 9, 2023
@MelvinBot
Copy link

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

@MelvinBot
Copy link

MelvinBot commented Mar 9, 2023

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

@kadiealexander
Copy link
Contributor

kadiealexander commented Mar 10, 2023

Reproduced on Mac OS in Chrome:

2023-03-10_14-48-48.copy.mp4

@kadiealexander kadiealexander added the External Added to denote the issue can be worked on by a contributor label Mar 10, 2023
@melvin-bot melvin-bot bot unlocked this conversation Mar 10, 2023
@melvin-bot melvin-bot bot changed the title Web - Emoji Reaction - Reaction emoji is highlighted twice when using Tab key [$1000] Web - Emoji Reaction - Reaction emoji is highlighted twice when using Tab key Mar 10, 2023
@MelvinBot
Copy link

Job added to Upwork: https://www.upwork.com/jobs/~010d30323d77b01052

@MelvinBot
Copy link

Current assignee @kadiealexander is eligible for the External assigner, not assigning anyone new.

@MelvinBot
Copy link

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

@melvin-bot melvin-bot bot added the Help Wanted Apply this label when an issue is open to proposals by contributors label Mar 10, 2023
@MelvinBot
Copy link

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

@bernhardoj
Copy link
Contributor

bernhardoj commented Mar 10, 2023

Proposal

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

The emoji reaction is highlighted twice when navigating using Tab key.

What is the root cause of that problem?

Currently, we have 2 ways of rendering a Tooltip and it is controlled by the absolute prop. If absolute is false, the Tooltip children will be wrapped by a View, otherwise none. The children then get wrapped by a Hoverable component with the same absolute prop which works the same way.

<Hoverable
absolute={this.props.absolute}
containerStyles={this.props.containerStyles}
onHoverIn={this.showTooltip}
onHoverOut={this.hideTooltip}
>
{child}
</Hoverable>

Let's look at the difference between setting the absolute to true and false. Let say we have this component.

<Tooltip>
    <Pressable />
</Tooltip>

The component above will be rendered like this:

absolute false

<View>                     <= View from Hoverable
    <View>                 <= View from Tooltip (focusable)
        <Pressable />   <= the children (focusable)
    <View />
</View>

absolute true

<Pressable />   <= the children (focusable)

As you can see above, rendering Tooltip with absolute false will render multiple view which one of them is focusable. This makes the keyboard tab will focus on the View first and then to the children (Pressable). With absolute true, all onMouseEnter, onMouseLeave, etc. will be attached to the children instead, which IMO is clearer. The old Tooltip component always wraps the children with a View, then the absolute prop is introduced by this PR to support Tooltip for an absolute positioned component, which I think should be the default way of rendering the Tooltip. However, absolute props will only work for a single child which makes total sense. If we have multiple children, then we obviously need a wrapper to handle the hovering.

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

As I said above, absolute true should be the default of Tooltip. It is much better so the hovering will really only happen on the area of the component that we wrap. For example, let say we have an avatar with a tooltip and absolute is set to false. The user will be able to hover over the edge of the tooltip component and the tooltip will show. With absolute to true, the tooltip will only show if we hover over the avatar component (the circle).

image

It sounds like I'm supporting to use the absolute prop, but I actually think that it's better to get rid of that prop. Why? Currently, our Tooltip handle the logic whether to wrap the Tooltip children with a View or not (which is basically the same as, if the children is an array, wrap it with a View, otherwise don't). At the end, all Tooltip children will be a single child. We can reduce the responsibility of our Tooltip component by removing the absolute prop, make sure the children are not multiple, and never wrap the children with a View. If we need to wrap the children with a View, do it inside the children, not inside the Tooltip component. This is the same as the TouchableOpacity component where we can't supply multiple children. This way, our Tooltip is only responsible for showing/hiding the Tooltip, nothing else. (this changes will also apply to Hoverable).

The above changes will also prevent such kind of this issue.

more info

The mentioned issue above easily happens if we wrap the Tooltip children with a View. For example:

<Tooltip>
    <Text style={{marginRight: 16}}/>
</Tooltip>

On screen, it looks fine. But because we have the margin right, we are able to hover over the right of the text by 16 and the tooltip will show and also it won't be center positioned. But with the changes suggested above, the issue will never happen because all the positioning and hovering logic is relative to the children.

Last thing, we shouldn't always set the focusable to true. (I assume we don't want a text with a tooltip is navigable through tab key.) Only set the focusable to true if the children have an onPress props, otherwise set it to false (Boolean(this.children.props.onPress)).

setting the focusable to false is actually the main point for the issue. The refactor is trying to make the component clearer and also prevent a Text to be navigable by tab key

I can open a draft PR if you want to see the changes needed.

What alternative solutions did you explore? (Optional)

(my previous main solution)
We should just set the focusable to false too at the emoji reaction inside mini context menu here.

<BaseMiniContextMenuItem
key={emoji.name}
isDelayButtonStateComplete={false}
tooltipText={`:${emoji.name}:`}
onPress={() => props.onEmojiSelected(emoji)}
>

const BaseMiniContextMenuItem = props => (
<Tooltip text={props.tooltipText}>
<Pressable

So, we can pass like tooltipFocusable to false and pass it to the tooltip focusable

@getusha
Copy link
Contributor

getusha commented Mar 10, 2023

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

Context menu item is highlighted twice ( have two focusable elements )

What is the root cause of that problem?

When using the tooltip's "View" feature to encompass any clickable component, it can lead to two elements being in focus while navigating via the "tab" key - the clickable element that performs an action and the non-interactive element.

<View
ref={el => this.wrapperView = el}
onBlur={this.hideTooltip}
focusable={this.props.focusable}
style={this.props.containerStyles}
>
{this.props.children}
</View>
);

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

We should add absolute prop to the context menu items tooltip
Screenshot 2023-03-09 at 7 24 51 PM

I previously expressed my concerns on this matter here, and while it was acknowledged and addressed, it was not implemented in the PR.

What alternative solutions did you explore? (Optional)

@parasharrajat
Copy link
Member

parasharrajat commented Mar 10, 2023

Thanks, everyone for the proposals. FYI, I have reviewed the proposals. But I need to confirm a few things before we move ahead on this issue.

Started with

@bernhardoj
Copy link
Contributor

I think this is the best time to do a little refactor to the Tooltip component.

The reason behind absolute is to have the tooltip hover area the same size as the component, but currently it will only work for a single child view, if there are multiple children, we need a wrapper which is totally makes sense. Here are some changes that we need:

We should just get rid of the absolute property and force every tooltip to only have a single child, similar to TouchableOpactiy. So, every tooltip that we have now that have multiple children need to be wrapped by a View (I only found one, AvatarWithIndicator ).
Set the focusable property to true only if the child is either TouchableOpacity, TouchableWithoutFeedback, & Pressable, otherwise set it to false. We don't want a touchable component to have focusable set to false.

This will solve all the current (double tab) issue and future issues like this one #15808 (there are several times this kind of issues getting reported).

@parasharrajat
Copy link
Member

@bernhardoj What and why is missing from proposal? I mean you didn't explain what are you trying to achieve in second paragraph and why.

Why should we get rid of absolute prop?
...
....
Etc

Do you mind following the format if you are proposing?

@bernhardoj
Copy link
Contributor

I have updated my proposal above to include the refactor explanation. I'm a little bit struggling to explain it, so if something is not clear/missing, please ask it 😄.

@s77rt
Copy link
Contributor

s77rt commented Mar 12, 2023

Proposal

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

Context Menu Items are Tabbable twice.

What is the root cause of that problem?

We have two nested focusable elements, the Pressable and the Tooltip. The Tooltip is made focusable intentionally here and this bug was addressed already but decided to be ignored as keyboard navigation was not a concern.

More context: I'm the author of the linked PR and the sole purpose of having the Tooltip focusable is so the blur event from its children bubbles up so we can hide it. That being said the Tooltip need to be focusable but not necessary tabbable i.e. tabIndex does not have to be 0 setting it to -1 is enough.

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

Set tabIndex of Tooltip to -1. This can be achieved by setting focusable to false here and here.

How focusable prop behaves on RNW (View):

  • focusable unset => tabIndex unset (not focusable and not tabbable)
  • focusable set to false => tabIndex = -1 (focusable but not tabbable)
  • focusable set to true => tabIndex = 0 (focusable and tabbable)

What alternative solutions did you explore? (Optional)

None

@MelvinBot
Copy link

Looks like something related to react-navigation may have been mentioned in this issue discussion.

As a reminder, please make sure that all proposals are not workarounds and that any and all attempt to fix the issue holistically have been made before proceeding with a solution. Proposals to change our DeprecatedCustomActions.js files should not be accepted.

Feel free to drop a note in #expensify-open-source with any questions.

@melvin-bot melvin-bot bot added the Overdue label Mar 13, 2023
@pecanoro
Copy link
Contributor

Not overdue, proposals still under review

@melvin-bot melvin-bot bot removed the Overdue label Mar 13, 2023
@melvin-bot
Copy link

melvin-bot bot commented Jun 29, 2023

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:

@parasharrajat
Copy link
Member

Last PR merged.

@melvin-bot melvin-bot bot added Daily KSv2 and removed Weekly KSv2 labels Jul 5, 2023
@kadiealexander
Copy link
Contributor

kadiealexander commented Jul 5, 2023

@parasharrajat before I issue an Upworks contract, are you being paid via NewDot now?

I've issued an Upworks contract to @bernhardoj :)

@bernhardoj
Copy link
Contributor

@kadiealexander I just realized there are 2 contracts on upwork

1
image

2
image

@parasharrajat
Copy link
Member

Please hold my payments for now.

@kadiealexander
Copy link
Contributor

@bernhardoj super weird! I've closed one and paid the other.

@parasharrajat, could you please complete this checklist while waiting for your NewDot payment?

@kadiealexander kadiealexander changed the title [HOLD for payment 2023-07-06] [$1000] Web - Emoji Reaction - Reaction emoji is highlighted twice when using Tab key [HOLD for newdot C+ payment] [$1000] Web - Emoji Reaction - Reaction emoji is highlighted twice when using Tab key Jul 7, 2023
@kadiealexander kadiealexander added Weekly KSv2 and removed Daily KSv2 labels Jul 7, 2023
@bernhardoj
Copy link
Contributor

@kadiealexander thanks!

@melvin-bot melvin-bot bot added the Overdue label Jul 17, 2023
@pecanoro
Copy link
Contributor

@parasharrajat Please, fill out the list whenever you have a few minutes so we can finally close this one!

@melvin-bot melvin-bot bot removed the Overdue label Jul 18, 2023
@parasharrajat
Copy link
Member

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:

Regression Test Steps

  1. Send a message
  2. Hover over the message to see the mini context menu.
  3. Select a quick reaction from the mini menu.
  4. Press the Tab key.
  5. Verify that each tab key selects the next action only once and the user doesn't need to press Tab twice on a single action to move to the next action.

Do you agree 👍 or 👎 ?

@melvin-bot melvin-bot bot added the Overdue label Jul 27, 2023
@pecanoro
Copy link
Contributor

@kadiealexander All yours!

@melvin-bot melvin-bot bot removed the Overdue label Jul 27, 2023
@pecanoro pecanoro added Daily KSv2 and removed Weekly KSv2 labels Jul 27, 2023
@kadiealexander
Copy link
Contributor

kadiealexander commented Jul 28, 2023

Completed Bug0 checklist: #15796 (comment)

Payouts due:

Eligible for 50% #urgency bonus? No

Upwork job is here.

@kadiealexander
Copy link
Contributor

All done, will shift to weekly while we wait for Newdot payment to be issued.

@kadiealexander kadiealexander added Weekly KSv2 and removed Daily KSv2 labels Jul 28, 2023
@parasharrajat
Copy link
Member

Payment Requested.

@JmillsExpensify
Copy link

Reviewed details for @parasharrajat. These details are accurate based on summary from Business Reviewer and are now approved for payment in NewDot.

@parasharrajat
Copy link
Member

We are good to close this @kadiealexander

Copy link

melvin-bot bot commented Dec 2, 2023

⚠️ 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Awaiting Payment Auto-added when associated PR is deployed to production Bug Something is broken. Auto assigns a BugZero manager. External Added to denote the issue can be worked on by a contributor Weekly KSv2
Projects
None yet
Development

No branches or pull requests

9 participants