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

[$250] mWeb/Chrome - Inbox - Blue frame on search icon after returning from finder with device back button #52128

Open
1 of 8 tasks
lanitochka17 opened this issue Nov 6, 2024 · 13 comments
Assignees
Labels
Bug Something is broken. Auto assigns a BugZero manager. Daily KSv2 External Added to denote the issue can be worked on by a contributor Help Wanted Apply this label when an issue is open to proposals by contributors

Comments

@lanitochka17
Copy link

lanitochka17 commented Nov 6, 2024

If you haven’t already, check out our contributing guidelines for onboarding and email [email protected] to request to join our Slack channel!


Version Number: 9.0.58-0
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught on HybridApp, is this reproducible on New Expensify Standalone?: N/A
If this was caught during regression testing, add the test name, ID and link from TestRail: N/A
Issue reported by: Applause - Internal Team

Action Performed:

  1. Open the staging.new.expensify.com website
  2. Tap on the search icon on the top right corner
  3. Write anything on the search input
  4. Return to inbox using device back button
  5. Verify that search icon remains the same

Expected Result:

No difference should be seen on search icon after opening finder, writing on search input and returning to inbox

Actual Result:

A blue frame is displayed around search icon after navigating to finder, writing on search input and returning to inbox using device back button

Workaround:

Unknown

Platforms:

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

  • Android: Standalone
  • Android: HybridApp
  • Android: mWeb Chrome
  • iOS: Standalone
  • iOS: HybridApp
  • iOS: mWeb Safari
  • MacOS: Chrome / Safari
  • MacOS: Desktop

Screenshots/Videos

Add any screenshot/video evidence
Bug6656631_1730902841381.Frame.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit
  • Upwork Job URL: https://www.upwork.com/jobs/~021854990083710446627
  • Upwork Job ID: 1854990083710446627
  • Last Price Increase: 2024-11-15
Issue OwnerCurrent Issue Owner: @rojiphil
@lanitochka17 lanitochka17 added Daily KSv2 Bug Something is broken. Auto assigns a BugZero manager. labels Nov 6, 2024
Copy link

melvin-bot bot commented Nov 6, 2024

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

@nyomanjyotisa
Copy link
Contributor

nyomanjyotisa commented Nov 6, 2024

Proposal

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

mWeb/Chrome - Inbox - Blue frame on search icon after returning from finder with device back button

What is the root cause of that problem?

This code applies a box-shadow to elements when they are in the focus-visible state

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

Add style.boxShadowNone to this line of style

What alternative solutions did you explore? (Optional)

Use pressableRef?.current?.blur() to blur the search button here when the user presses it. This approach prevents issues when the user wants to navigate to the search button using the Tab key

                onPress={Session.checkIfActionIsAllowed(() => {
                    pressableRef?.current?.blur();
                    Timing.start(CONST.TIMING.SEARCH_ROUTER_RENDER);
                    Performance.markStart(CONST.TIMING.SEARCH_ROUTER_RENDER);

                    openSearchRouter();
                })}

Result

mWeb.Chrome.mp4

@truph01
Copy link
Contributor

truph01 commented Nov 7, 2024

Proposal

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

  • Blue outline appears on the search icon after returning from Finder using the device's back button (or swipe-right action), but not when tapping the app's back button ('<') in the top left.

What is the root cause of that problem?

  • In HTML, an element receives the focus-visible pseudo-class (typically displaying a visible border or outline by default, and unrelated to our custom focus-visible as defined here) when focused in a way that usually requires a visible indicator. This behavior varies depending on user interaction:
  1. Keyboard Focus: If the user navigates to the element using the keyboard (like pressing the Tab key), the focus-visible class is applied to indicate the focused element.

  2. Programmatic Focus with focus(): If you programmatically focus the element using JavaScript (element.focus()) and the element is focusable, the browser may add the focus-visible class based on its heuristics for showing focus indicators.

  3. Not Applied on Mouse Clicks: Generally, if an element receives focus due to a mouse click, the focus-visible class is not applied, as browsers usually suppress the focus indicator in this case.

  • The behavior I`ve mentioned:

Blue outline appears on the search icon after returning from Finder using the device's back button (or swipe-right action), but not when tapping the app's back button ('<') in the top left.

relates to conditions in points 1 and 3 above.

  • In detail:

Device Back Button or Swipe-Right Action: When the search icon is clicked and a keyboard interaction occurs, the focus-visible class is applied, marking the element as focused. Exiting via the device’s back button or swipe-right keeps the focus-visible indicator on the search icon.

App Back Button (‘<’): If the search icon is clicked, then a keyboard action occurs, the focus-visible class is initially applied. However, when the app’s back button is pressed, the browser, recognizing this as a mouse action, suppresses the focus-visible indicator, leaving the search icon without the focus-visible class.

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

  • To solve the issue, we just need to prevent search button from being focused when clicking on it:

            <PressableWithoutFeedback
                onMouseDown={(e) => e.preventDefault()}

What alternative solutions did you explore? (Optional)

@MitchExpensify MitchExpensify added the External Added to denote the issue can be worked on by a contributor label Nov 8, 2024
@melvin-bot melvin-bot bot changed the title mWeb/Chrome - Inbox - Blue frame on search icon after returning from finder with device back button [$250] mWeb/Chrome - Inbox - Blue frame on search icon after returning from finder with device back button Nov 8, 2024
Copy link

melvin-bot bot commented Nov 8, 2024

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

@melvin-bot melvin-bot bot added Overdue Help Wanted Apply this label when an issue is open to proposals by contributors labels Nov 8, 2024
Copy link

melvin-bot bot commented Nov 8, 2024

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

@melvin-bot melvin-bot bot removed the Overdue label Nov 8, 2024
@ikevin127
Copy link
Contributor

Proposal

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

A blue frame is displayed around search icon after navigating to finder, writing on search input and returning to inbox using device back button.

What is the root cause of that problem?

We are applying the :focus-visible pseudo-class styling at the index.html level which applies to all web based platforms (Web, Desktop, Android / iOS mWeb), the pseudo-class is applied in two distinct places:

App/web/index.html

Lines 65 to 67 in 0f03601

:focus-visible {
outline: 0;
box-shadow: inset 0px 0px 0px 1px #5AB0FF;

and

App/web/index.html

Lines 83 to 86 in 0f03601

:focus[data-focusvisible-polyfill] {
outline: 0;
box-shadow: inset 0px 0px 0px 1px #5AB0FF;
}

the root cause of our issue being that the pseudo-class style is applied globally to all web based platforms, including mWeb without any exclusion.

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

There's a simple and practical CSS-based solution to keep the :focus-visible pseudo-class styling only on devices with cursor pointers (Web / Desktop) and not on touch based devices (Android / iOS mWeb).

To do this we will use the widely supported feature @media: pointer with the coarse value which represents:

The primary input mechanism of the device includes a pointing device of limited accuracy. Examples include touchscreens and motion-detection sensors (like the Kinect peripheral for the Xbox.)

In order to cover both instances where we use the :focus-visible pseudo-class style, we will add the fix under this style block (cascading) such that it will apply to both of them since they are located above, like so:

/* Our first pseudo-class style */
:focus-visible {
    outline: 0;
    box-shadow: inset 0px 0px 0px 1px #5AB0FF;
}

/* ... */

/* Our second pseudo-class style */
:focus[data-focusvisible-polyfill] {
    outline: 0;
    box-shadow: inset 0px 0px 0px 1px #5AB0FF;
}
/* Disable the box-shadow for coarse (touch) pointers */ <- Added our fix right here
@media (pointer: coarse) {
    :focus-visible, :focus[data-focusvisible-polyfill] {
        box-shadow: none;
    }
}
<- End of fix

✅ This ensures the focus effect still stands on Web / Desktop but it won't show up on Android / iOS mWeb anymore, fulfilling the issue's Expected result.

Note

I think it is paramount that we keep the focus visual feedback on the search icon for Web / Desktop platforms for accessibility reasons.

Videos (before / after)

Android: mWeb
Before After
before.mp4
after.mp4

Copy link

melvin-bot bot commented Nov 12, 2024

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

@melvin-bot melvin-bot bot added the Overdue label Nov 12, 2024
@MitchExpensify
Copy link
Contributor

@rojiphil can you review the proposals here please?

Copy link

melvin-bot bot commented Nov 14, 2024

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

@rojiphil
Copy link
Contributor

can you review the proposals here please?

Sorry for the delay here. Will review today.

@melvin-bot melvin-bot bot removed the Overdue label Nov 14, 2024
Copy link

melvin-bot bot commented Nov 15, 2024

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

@rojiphil
Copy link
Contributor

Thanks for all your proposals.

@nyomanjyotisa Adding style.boxShadowNone does not seem to be the way to go as the blue frame on search icon will not be displayed when needed (e.g. navigation using tab)

@truph01 Preventing the search button from being focused also does not seem like a good idea as keyboard access is still needed on the button.

This ensures the focus effect still stands on Web / Desktop but it won't show up on Android / iOS mWeb anymore, fulfilling the issue's Expected result.

@ikevin127 I think the expected result is to not display the blue frame on android mweb chrome when device back button is pressed. It does not look like we don’t want to show that on iOS/Android mWeb anymore. Or am I missing something here?

@ikevin127
Copy link
Contributor

ikevin127 commented Nov 15, 2024

Expected Result:
No difference should be seen on search icon after opening finder, writing on search input and returning to inbox

@rojiphil What I understand is that we don't want to see the focus effect in our case on any mWeb platform (touch devices, narrow layout) - meaning to have consistency with Native platforms. The only place where the focus effect should be kept is Web / Desktop for accessibility reasons (because here we can navigate with keyboard and need visual feedback).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug Something is broken. Auto assigns a BugZero manager. Daily KSv2 External Added to denote the issue can be worked on by a contributor Help Wanted Apply this label when an issue is open to proposals by contributors
Projects
None yet
Development

No branches or pull requests

6 participants