[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 [email protected] 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

[aimane-chnaif]

I think this can be closed. If this should be fixed, original contributors in #31717 should handle this as follow-up as they enabled this feature.

[mountiny]

its pass the regression period but I think they knew about it so maybe we can just tag @puneetlath @c3024 @s-alves10

[puneetlath]

Yes, my understanding is that the two letter codes is what windows renders for these emojis. It's not a workaround on our part. It's just what the system is doing and it's not a bug. Feel free to reopen/comment if you disagree.

[dragnoir]

Below a screenshot from Slack web app (flags) and same for other web apps on windows.

I think it's not good for UX and for the app to allow using emoji unicode with a font that does not support it.
The issue is not from Windows. The issue is that we are asking "Segoe UI Emoji" to dispplay unsupported emoji.

[mountiny]

@dragnoir Can you give more details about the implementation, we are trying to avoid platform specific code, even more so operating system specific one

[mountiny]

@deetergp Discussed this here btw

[aimane-chnaif]

@dragnoir can you share Noto Color Emoji font file? or share test branch

[dragnoir]

@aimane-chnaif link for the font: https://fonts.google.com/noto/specimen/Noto+Color+Emoji
@mountiny I will update my proposal for more details

[s-alves10]

@mountiny @aimane-chnaif

This was done by intention in #31717. We added supports for flags emojis on Windows and those are flag emojis(not country code) by the font
I don't think this is a bug

[aimane-chnaif]

@s-alves10 https://expensify.slack.com/archives/C01GTK53T8Q/p1704373190191139

[s-alves10]

Okay, if we need to fix this, yeah, the use of proper font is the right way, I think.
We should check if the new font has other side effects anyway

[deetergp]

The consensus is that nobody feels super passionate about it, but if it's an easy fix, then we should go ahead and fix it.

[melvin-bot]

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

[melvin-bot]

Current assignee @aimane-chnaif is eligible for the External assigner, not assigning anyone new.

[kadiealexander]

Payouts due:

• Contributor: $500 @dragnoir
• Contributor+: $500 @aimane-chnaif

Upwork job is here.

[kadiealexander]

Contracts sent!

[iwiznia]

Sorry but I just realized we did this and correct me if I am wrong but:

• We added a new font that's 5.4MB
• This is only so that windows, which does not have flag emojis, can display the flag emojis
• We are loading this file for every user, even people that are not on windows

Is that all correct?

[shawnborton]

Yeah, just seeing this now and echoing the same concern as Ionatan above - I think we picked a bad solution for this and we should revert what was implemented.

[iwiznia]

Yep. I think we should just revert this and leave the "broken" flag emojis on window.

If people feel passionate that it should work, then we should make it only load for windows users AND reduce the size of the font (maybe by removing all emojis that are not flags?)

[dragnoir]

@iwiznia another issue to consider is:

• User A on a non-windows device sends a message to user B, the message use flags
• User B on Windows, will not be able to see the flags, but some characters like AM

[iwiznia]

Yes, I know, windows users will use the flag icons that windows has, which apparently is just initials of the place.

[melvin-bot]

Reviewing label has been removed, please complete the "BugZero Checklist".

[melvin-bot]

The solution for this issue has been 🚀 deployed to production 🚀 in version 1.4.54-4 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:

• Fix: add Noto Color Emoji to support flags on Windows #35790
• Revert "Merge pull request #35790 from dragnoir/33653-fix" #38408

If no regressions arise, payment will be issued on 2024-03-26. 🎊

For reference, here are some details about the assignees on this issue:

• @dragnoir requires payment (Needs manual offer from BZ)
• @aimane-chnaif requires payment (Needs manual offer from BZ)

[melvin-bot]

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:

• [@aimane-chnaif] The PR that introduced the bug has been identified. Link to the PR:
• [@aimane-chnaif] 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:
• [@aimane-chnaif] A discussion in #expensify-bugs 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:
• [@aimane-chnaif] Determine if we should create a regression test for this bug.
• [@aimane-chnaif] If we decide to create a regression test for the bug, please propose the regression test steps to ensure the same bug will not reach production again.
• [@kadiealexander] Link the GH issue for creating/updating the regression test once above steps have been agreed upon: