[HOLD for payment 2024-03-26] [$500] [Hold for payment 2024-02-22] Web - Most of the flag icons are replaced by country codes

[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.4.18.1
Reproducible in staging?: y
Reproducible in production?: n
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: Applause - Internal Team
Slack conversation:

Issue found when executing PR #33603

Action Performed:

1. Navigate to https://staging.new.expensify.com/
2. Open emoji picker
3. Click on the "flag" category
4. Scroll down

Expected Result:

Actual flags should be added. Black ones should be replaced.

Actual Result:

Most of the flag icons are replaced by country codes. Some of them are just black.

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

Bug6326895_1703696523699.bandicam_2023-12-27_17-41-01-308.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~01bb535f38757934f7
• Upwork Job ID: 1760839254159802368
• Last Price Increase: 2024-02-23

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

[melvin-bot]

Triggered auto assignment to @deetergp (Engineering), see https://stackoverflow.com/c/expensify/questions/4319 for more details.

[abzokhattab]

I cannot reproduce it:

[deetergp]

I am also not seeing this. Don't think it's a blocker.

[dragnoir]

Proposal

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

Flag icons are not accessible on windows.

What is the root cause of that problem?

We are encountering an issue where flag icons are not rendered correctly on Windows platforms within the application. This problem affects the accessibility and visual consistency of the UI.

To address the root cause, let's delve into the process of how browsers handle fonts, particularly for rendering emojis.
Consider a simple text element <Text>Hello</Text> styled with a font, say FontBetaX, as follows:
And we need the app to use FontBetaX (just as an example). We do in styling this line:

font-family: FontBetaX;

The browser's rendering process is two-fold:

1. Font Loading: It checks if FontBetaX is loaded from the server:

@font-face {
  font-family: ExpensifyNeue-Regular;
  src: url('../assets/fonts/web/FontBetaX.woff') format('woff');
}

2. Fallback Fonts: If not loaded from the server, the browser defaults to system-installed fonts.

In the context of our app, specifically for emojis, the font styling is defined as:

const  fontFamily:  FontFamilyStyles  = {
  EXP_NEUE: 'ExpensifyNeue-Regular, Segoe UI Emoji, Noto Color Emoji',
};

and then we use it in styling of the components

App/src/styles/index.ts

Line 220 in 85fee5a

fontFamily: FontUtils.fontFamily.platform.EXP_NEUE,

On the browser, this translates to:

font-family: ExpensifyNeue-Regular, "Windows Segoe UI Emoji", "Noto Color Emoji";

Here’s the process the browser follows:

1. The browser will check if the ExpensifyNeue-Regular font is loaded from the app server (Yes it is)
2. The browser will check if the font ExpensifyNeue-Regular support the emoji (No the font doesn't support the emoji).
3. The browser will move to the next font, Segoe UI Emoji, and check if it's imported from the server (No, we don't import this font)
4. The browser will check if the system has this font (Yes, windows has by default the Segoe family font)
5. The browser then will use this font the render the emoji (This cause the issue because Segoe render flags as characters)

In contrast, on Ubuntu, none of the fonts are supported by default, resulting in emojis not displaying correctly, as shown in the attached screenshot from Ubuntu.

The core issue lies in our reliance on default system fonts for emoji rendering, which varies across platforms:

• Android uses Noto Color Emoji iOS
• macOS use Apple Color Emoji
• Windows and use Segoe UI Emoji
  A more robust approach is to serve a consistent emoji font from our server, as we do with ExpensifyNeue-Regular.

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

To resolve this on Windows, we should serve a universally compatible emoji font from our server. I suggest Noto Color Emoji (already in use on Android devices). The implementation steps are:

1. Add the font file to the folder /assets/fonts/web
2. Import the Noto font here
3. Apply the Noto Color Emoji font on Emojies on Windows and not Windows Segoe UI Emoji by changing the order of the fonts in the style.

font-family: ExpensifyNeue-Regular, "Noto Color Emoji";

What alternative solutions did you explore? (Optional)

We observed that the Expensify app currently renders emojis differently across platforms, as demonstrated in the attached screenshot comparing Windows and Android emojis.

An alternative approach would be to standardize the emoji style across all platforms, akin to platforms like Slack. This would enhance consistency in our user experience.

[dragnoir]

@deetergp the issue is only on Windows

[mountiny]

I think this was expected, and its known that on windows the flag emojis are not working perfectly.

it would be great to avoid any kind of workarounds if we want to fix this