You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[HOLD for payment 2024-12-07] [$250] mWeb/Chrome - Inbox - Blue frame on search icon after returning from finder with device back button #52128
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:
Open the staging.new.expensify.com website
Tap on the search icon on the top right corner
Write anything on the search input
Return to inbox using device back button
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 evidenceBug6656631_1730902841381.Frame.mp4
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
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:
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.
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.
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:
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[/+]on Nov 8, 2024
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:
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).
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 0px0px0px1px#5AB0FF;}/* ... *//* Our second pseudo-class style */:focus[data-focusvisible-polyfill] {outline:0;box-shadow: inset 0px0px0px1px#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 / iOSmWeb 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.
changed the title [-][$250] mWeb/Chrome - Inbox - Blue frame on search icon after returning from finder with device back button[/-][+][HOLD for payment 2024-12-07] [$250] mWeb/Chrome - Inbox - Blue frame on search icon after returning from finder with device back button[/+]on Nov 30, 2024
The solution for this issue has been 🚀 deployed to production 🚀 in version 9.0.68-7 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:
@rojiphil@MitchExpensify@rojiphil The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed. Please copy/paste the BugZero Checklist from here into a new comment on this GH and complete it. If you have the K2 extension, you can simply click: [this button]
[Contributor] If the regression was CRITICAL (e.g. interrupts a core flow) A discussion in #expensify-open-source 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: Not Required. The existing checklist is good enough to capture such issues.
[Contributor] If it was decided to create a regression test for the bug, please propose the regression test steps using the template below to ensure the same bug will not reach production again.
Regression Test Proposal
Precondition:
Note: Test on android native/mweb platform
Test:
Tap on the search icon on LHN
Enter a search string in the search input
Use device back button to return to LHN
Verify that search icon does not show the blue frame.
Activity
melvin-bot commentedon 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 commentedon 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-shadowto elements when they are in thefocus-visiblestateWhat changes do you think we should make in order to solve the problem?
Add
style.boxShadowNoneto this line of styleWhat 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 keyResult
mWeb.Chrome.mp4
truph01 commentedon Nov 7, 2024
Proposal
Please re-state the problem that we are trying to solve in this issue.
What is the root cause of that problem?
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.
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.
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.
relates to conditions in points 1 and 3 above.
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?
App/src/components/Search/SearchRouter/SearchButton.tsx
Line 28 in 0f03601
What alternative solutions did you explore? (Optional)
[-]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[/+]melvin-bot commentedon Nov 8, 2024
Job added to Upwork: https://www.upwork.com/jobs/~021854990083710446627
melvin-bot commentedon Nov 8, 2024
Triggered auto assignment to Contributor-plus team member for initial proposal review - @rojiphil (
External)ikevin127 commentedon Nov 10, 2024
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-visiblepseudo-class styling at theindex.htmllevel 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
and
App/web/index.html
Lines 83 to 86 in 0f03601
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-visiblepseudo-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: pointerwith thecoarsevalue which represents:In order to cover both instances where we use the
:focus-visiblepseudo-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:✅ 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.mp4
after.mp4
37 remaining items
[-][$250] mWeb/Chrome - Inbox - Blue frame on search icon after returning from finder with device back button[/-][+][HOLD for payment 2024-12-07] [$250] mWeb/Chrome - Inbox - Blue frame on search icon after returning from finder with device back button[/+]melvin-bot commentedon Nov 30, 2024
Reviewinglabel has been removed, please complete the "BugZero Checklist".melvin-bot commentedon Nov 30, 2024
The solution for this issue has been 🚀 deployed to production 🚀 in version 9.0.68-7 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:
If no regressions arise, payment will be issued on 2024-12-07. 🎊
For reference, here are some details about the assignees on this issue:
melvin-bot commentedon Nov 30, 2024
@rojiphil @MitchExpensify @rojiphil The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed. Please copy/paste the BugZero Checklist from here into a new comment on this GH and complete it. If you have the K2 extension, you can simply click: [this button]
rojiphil commentedon Dec 9, 2024
BugZero Checklist:
Bug classification
Source of bug:
Where bug was reported:
Who reported the bug:
[Contributor] 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:
[Contributor] If the regression was CRITICAL (e.g. interrupts a core flow) A discussion in #expensify-open-source 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: Not Required. The existing checklist is good enough to capture such issues.
[Contributor] If it was decided to create a regression test for the bug, please propose the regression test steps using the template below to ensure the same bug will not reach production again.
Regression Test Proposal
Precondition:
Note: Test on android native/mweb platform
Test:
Do we agree 👍 or 👎
rojiphil commentedon Dec 9, 2024
@MitchExpensify Completed BZ checklist and accepted the offer too. All yours now. Thanks.
MitchExpensify commentedon Dec 10, 2024
Test GH here: https://github.com/Expensify/Expensify/issues/451967
Paid and contracts ended