[$250] mWeb – Chat – Blue frame appears around + button when open conversation link URL in a new tab

[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: 9.0.11-2
Reproducible in staging?: Y
Reproducible in production?: N
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. Go to https://staging.new.expensify.com/
2. Log in with Gmail account
3. Open any chat and copy URL
4. Open new tab and paste URL

Expected Result:

Chat opens without blue frame around + button

Actual Result:

Chat opens with blue frame around + button

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

Add any screenshot/video evidence

Bug6551355_1721811739477.Blue_frame__.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~011ced2d499965abe3
• Upwork Job ID: 1816181351346781688
• Last Price Increase: 2024-08-21
• Automatic offers:
• tsa321 | Contributor | 103953960

Issue Owner

Current Issue Owner: @sobitneupane

[melvin-bot]

Triggered auto assignment to @srikarparsi (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

[github-actions]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[lanitochka17]

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

[lanitochka17]

Issue is not reproducible on Production:

Screenrecorder-2024-07-24-16-05-10-406.mp4

[francoisl]

Possibly related to #45743 (?) Anyway, doesn't look like something worth blocking for – going to demote.

[melvin-bot]

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

[melvin-bot]

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

[srikarparsi]

Hi @tsa321 @hoangzinh, if you have a second, do you think you could check if this issue is related to #45743

[tsa321]

@srikarparsi, I have tried reverting my PR, but this issue is still reproducible.

[tsa321]

Edited by proposal-police: This proposal was edited at 2024-08-13 12:48:11 UTC.

Proposal

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

Blue border appears on + button when user open report by url

What is the root cause of that problem?

We use focusTrap to maintain tab navigation. When a user visits a page via URL, focusTrap initially focuses on the tabbable element, causing the blue border to appear. This issue is not limited to the report page; it occurs on several other pages as well, such as the About page, Profile page, Workspace List page, and briefly in the display name field, etc

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

We can disable the blue border using CSS styling when the page loads. We can then enable the blue border only when the user presses the Tab key. If any other key is pressed, we should disable the blue border again. The code could be:

let sheet;
const mangaeFocusedElementBlueBorder = () => {
    if (!document?.body) {
        return;
    }
    sheet = document.createElement('style');
    sheet.innerHTML = '[tabindex="0"]:focus{box-shadow: none; outline: none;}'
    document.body.appendChild(sheet);
    window.addEventListener('keydown', (e) => {
        if (e.key === 'Tab' || e.key === 'Shift') {
            if (e.key === 'Tab' && !!sheet.parentNode) {
                sheet.parentNode.removeChild(sheet);
            }
        } else if (!sheet.parentNode) {
            document.body.appendChild(sheet);
        }
    }, true);
}

We could place it in the Accessbility library

For the css selector, we could use *:focus instead of [tabindex="0"]:focus

What alternative solutions did you explore? (Optional)

In the FocusTrapForScreen option:

App/src/components/FocusTrap/FocusTrapForScreen/index.web.tsx

Lines 44 to 45 in 59741d8

	focusTrapOptions={{
	trapStack: sharedTrapStack,

we could add an onActivate property with the function: () => document?.activeElement?.blur(). Then, in initialFocus:

App/src/components/FocusTrap/FocusTrapForScreen/index.web.tsx

Lines 49 to 59 in 59741d8

	initialFocus: (focusTrapContainers) => {
	if (!canFocusInputOnScreenFocus()) {
	return false;
	}
	const isFocusedElementInsideContainer = focusTrapContainers?.some((container) => container.contains(document.activeElement));
	if (isFocusedElementInsideContainer) {
	return false;
	}
	return undefined;
	},

we should always return false there.

The focus trap already listens for the focus event and will check whether the focused element is inside the element to which it is attached (in this case, inside the screen) and will automatically move the focus inside the screen if it is outside.

What alternative solutions did you explore? (2)

To also fix this in strict mode, we could add activeElementRef and include onActivate and onDeactivate options in focusTrapOptions. In onActivate, we store the current active element in the ref, then blur it; in onDeactivate, we focus that element or if don't want to return the we don't need the onDeactivate callback. We must also set initialFocus and setReturnFocus to always return false. I have created a test branch to highlight the code changes.

[sobitneupane]

Thanks for your proposal @tsa321

Can you please elaborate the root cause section of your proposal?

When a user visits a page via URL, focusTrap initially focuses on the tabbable element, causing the blue border to appear.

Can you please link the code which implements above feature? Let's try to investigate more on the root cause.

Why is the issue limited to some pages only?

[tsa321]

@sobitneupane,

Here:

App/src/components/FocusTrap/FocusTrapForScreen/index.web.tsx

Lines 45 to 54 in 08bb00b

	initialFocus: (focusTrapContainers) => {
	if (!canFocusInputOnScreenFocus()) {
	return false;
	}
	const isFocusedElementInsideContainer = focusTrapContainers?.some((container) => container.contains(document.activeElement));
	if (isFocusedElementInsideContainer) {
	return false;
	}
	return undefined;

In the initialFocus of focusTrap, if the return value is false, the focusTrap will not automatically focus on a tabbable element inside the screen. However, if the return value is undefined, the focusTrap will focus on an element inside it.

(Assuming the return value of initialFocus is undefined.) When a user opens a page by clicking a button, the blue border won't appear. However, when the user refreshes the page or opens it by pressing a keyboard key (for example, pressing Enter on a button), the blue border will appear. This is the default behavior of web browsers for tab navigation.

[melvin-bot]

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

[melvin-bot]

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

[tsa321]

Kindly bump for proposal review, thanks.

[srikarparsi]

Asked in the swm channel since I'm not too familiar with focus trap.

[melvin-bot]

@sobitneupane, @srikarparsi 8 days overdue is a lot. Should this be a Weekly issue? If so, feel free to change it!

[mvtglobally]

Issue not reproducible during KI retests. (Second week)

[srikarparsi]

I'm not able to reproduce this either, @sobitneupane can you check if this is reproducible for you.

[tsa321]

@srikarparsi This issue is still reproducible when refreshing other pages: such as the Preferences page, Workspace list page, Profile page, About page, many other pages.

[sobitneupane]

@srikarparsi I can still reproduce the issue.

Screen.Recording.2024-09-10.at.17.03.38.mov

[srikarparsi]

Ah okay, I think @adamgrzybowski will be back tomorrow based on this comment so he might be able to better evaluate this proposal

[adamgrzybowski]

Hey! I was working on a focus trap at some point but it changed a lot since then. However, with my limited context, the alternative solution 2 looks like a right direction to me

[mvtglobally]

Issue not reproducible during KI retests. (Third week)

[melvin-bot]

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

[youssef-lr]

This is still reproducible

[srikarparsi]

Cool lets proceed with solution 2 then, assigning @tsa321

[melvin-bot]

📣 @tsa321 🎉 An offer has been automatically sent to your Upwork account for the Contributor role 🎉 Thanks for contributing to the Expensify app!

Offer link
Upwork job
Please accept the offer and leave a comment on the Github issue letting us know when we can expect a PR to be ready for review 🧑‍💻
Keep in mind: Code of Conduct | Contributing 📖

[melvin-bot]

This issue has not been updated in over 15 days. @sobitneupane, @srikarparsi, @tsa321 eroding to Monthly issue.

P.S. Is everyone reading this sure this is really a near-term priority? Be brave: if you disagree, go ahead and close it out. If someone disagrees, they'll reopen it, and if they don't: one less thing to do!

[sobitneupane]

PR deployed to production. Ready for payment.

[sobitneupane]

@srikarparsi This is ready for payment.