Make WordPress Core

Opened 17 months ago

Last modified 2 weeks ago

#63451 new defect (bug)

Flag emoji rendering issue on Windows environment

Reported by: kimjiwoon Owned by:
Priority: normal Milestone: Awaiting Review
Component: Emoji Version:
Severity: normal Keywords: close has-patch has-unit-tests
Cc: Focuses:

Description (last modified by dd32)

Title:
Flag emoji rendering issue on Windows environment

Description:
On WordPress, flag emojis for England (🏴󠁧󠁢󠁥󠁮󠁧󠁿), Scotland (🏴󠁧󠁢󠁳󠁣󠁴󠁿), and Wales (🏴󠁧󠁢󠁷󠁬󠁳󠁿) do not render correctly in Windows environments. Instead of showing their respective flag designs, they are displayed as a plain black flag (🏴).

On mobile devices (such as Android or iOS), these flag emojis render properly as intended using either system emojis or Twemoji fallback. However, on Windows 10/11 desktop systems, particularly with the Segoe UI Emoji font, the emoji tag sequences required for these regional flags are not supported, causing them to appear as a generic black flag.

Steps to Reproduce:

  1. Post a comment or content on a WordPress site containing these emojis:
  • 🏴󠁧󠁢󠁥󠁮󠁧󠁿 (England)
  • 🏴󠁧󠁢󠁳󠁣󠁴󠁿 (Scotland)
  • 🏴󠁧󠁢󠁷󠁬󠁳󠁿 (Wales)
  1. View the page on:
  • Mobile (Android/iOS) → Emoji display correctly
  • Windows 10/11 desktop → Displays as 🏴 black flag

Expected Result:
England, Scotland, and Wales flag emojis should render properly across platforms, or at least gracefully fallback via Twemoji when system font support is lacking.

Actual Result:
On Windows, all three flag emojis appear as 🏴.

Additional Info:

  • Confirmed on latest WordPress.com and WordPress.org self-hosted sites.
  • Twemoji appears to correctly render these on other platforms like Mastodon, X.com (Twitter), and Misskey.
  • Possible workaround: Ensure Twemoji or another fallback emoji library handles emoji tag sequences on desktop platforms where system fonts lack support.

Related Links:

​https://wordpress.com/support/emoji/
​https://x.com/thaumiel999/status/1923038246533001630
​https://mastodon.social/@thaumiel999/114512564948217544
​https://misskey.io/notes/a7t3kaiafyr70boz
​https://kimjiwoon96.wordpress.com/2025/02/16/%EC%95%84%ED%8C%8C%ED%8A%B8-%EC%98%A5%EC%83%81/comment-page-1/#comment-54

Attachments (1)

Screenshot 2025-08-12 at 10.22.09 am.png​ (20.5 KB ) - added by peterwilsoncc 14 months ago.

Download all attachments as: .zip

Change History (13)

#1 in reply to: ↑ description @canmerkat
14 months ago

I have had the same problem with Twenty Twenty as well. I remove the flag now on my post and watching ticket to be solved. Please check the screenshot. ​https://prnt.sc/9mfA7a4CjNAI

Replying to kimjiwoon:

Title:
Flag emoji rendering issue on Windows environment

Description:
On WordPress, flag emojis for England (🏴󠁧󠁢󠁥󠁮󠁧󠁿), Scotland (🏴󠁧󠁢󠁳󠁣󠁴󠁿), and Wales (🏴󠁧󠁢󠁷󠁬󠁳󠁿) do not render correctly in Windows environments. Instead of showing their respective flag designs, they are displayed as a plain black flag (🏴).

On mobile devices (such as Android or iOS), these flag emojis render properly as intended using either system emojis or Twemoji fallback. However, on Windows 10/11 desktop systems, particularly with the Segoe UI Emoji font, the emoji tag sequences required for these regional flags are not supported, causing them to appear as a generic black flag.

Steps to Reproduce:

  1. Post a comment or content on a WordPress site containing these emojis:
  • 🏴󠁧󠁢󠁥󠁮󠁧󠁿 (England)
  • 🏴󠁧󠁢󠁳󠁣󠁴󠁿 (Scotland)
  • 🏴󠁧󠁢󠁷󠁬󠁳󠁿 (Wales)
  1. View the page on:
  • Mobile (Android/iOS) → Emoji display correctly
  • Windows 10/11 desktop → Displays as 🏴 black flag

Expected Result:
England, Scotland, and Wales flag emojis should render properly across platforms, or at least gracefully fallback via Twemoji when system font support is lacking.

Actual Result:
On Windows, all three flag emojis appear as 🏴.

Additional Info:

  • Confirmed on latest WordPress.com and WordPress.org self-hosted sites.
  • Twemoji appears to correctly render these on other platforms like Mastodon, X.com (Twitter), and Misskey.
  • Possible workaround: Ensure Twemoji or another fallback emoji library handles emoji tag sequences on desktop platforms where system fonts lack support.

Related Links:

​https://wordpress.com/support/emoji/
​https://x.com/thaumiel999/status/1923038246533001630
​https://mastodon.social/@thaumiel999/114512564948217544
​https://misskey.io/notes/a7t3kaiafyr70boz
​https://kimjiwoon96.wordpress.com/2025/02/16/%EC%95%84%ED%8C%8C%ED%8A%B8-%EC%98%A5%EC%83%81/comment-page-1/#comment-54

Last edited 14 months ago by canmerkat (previous) (diff)

#2 @dd32
14 months ago

  • Description modified (diff)

This was rendering all Black flags everywhere, I think the emoji's were all black flag rather than the intended country flags. I've edited it to use the correct emoji flags for testing.

#3 @dd32
14 months ago

I couldn't duplicate this on Windows 10 Pro with Edge & Chrome.

Creating a post from Mac and viewing in Windows resulted in twemoji fallbacks.

Commenting with an emoji showed the black flag in places where the system font is used (Within the textbox) but posted as the emoji and twemoji kicked in for the comment preview.

#4 @peterwilsoncc
14 months ago

Reproduction Report

Description

I've attempted to reproduce this without success.

Using Chrome 139 on Windows 10 (via Browserstack), the emoji initially render as black flags due to a lack of system support but are subsequently replaced with the Twemoji images when rendered on the front end of the site.

In the Block editor the Twemoji script doesn't run so the render as black flags there but not for readers of the site.

@kimjiwoon if you're seeing this issue on the front-end of the site, are you able to provide further details about the browser and operating system versions?

Environment

  • WordPress: 6.9-alpha-60093-src
  • PHP: 8.3.23
  • Server: nginx/1.18.0
  • Database: mysqli (Server: 8.0.36-0ubuntu0.22.04.1 / Client: mysqlnd 8.3.23)
  • Browser: Chrome 139.0.0.0 via BrowserStack
  • OS: Windows 10/11
  • Theme: Twenty Twenty-Five 1.3
  • MU Plugins:
    • cpt-test.php
    • _admin_bar_show_cache.php
    • _qm-mappings.php
  • Plugins:
    • Query Monitor 3.19.0
    • Test Reports 1.2.0

Actual Results

Unable to reproduce

Supplemental Artifacts

See Screenshot 2025-08-12 at 10.22.09 am.png​

#5 @kimjiwoon
14 months ago

Reply to @peterwilsoncc

The issue appears to be resolved on my WordPress sites — the England, Scotland, and Wales flags are now rendering correctly on Windows where they previously appeared as 🏴 black flags.

However, in the WordPress Core Trac interface, these emojis still render as black flags on Windows.
This suggests the fix may be environment-specific (possibly front-end Twemoji fallback working, but not in Trac's rendering).

Were there any related patches in the past three months?
Could the recent ActivityPub plugin patch regarding multibyte character handling be related?
Reference: [wordpress-activitypub/pull/1995](​https://github.com/Automattic/wordpress-activitypub/pull/1995)

---

Tested with the following flag emojis using ActivityPub and Mastodon:

Steps:

  1. Posted a comment from Mastodon to a WordPress site with ActivityPub enabled → emojis rendered correctly on the front-end.
  2. Copied the same comment content and posted it manually on a self-hosted WordPress site → emojis rendered correctly as well.

This suggests that at least in front-end rendering (both ActivityPub-federated and manual comment posts), Twemoji fallback works properly now.

However:

  • In WordPress Core Trac, the same flag emojis still render as 🏴 black flags on Windows.
  • Possibly unrelated, but on WordPress.com the block editor is enabled for comments, and when inserting these emojis there, they are sometimes added as image elements instead of Unicode characters.

---

For reference, the flags appearing correctly above were pasted using the advanced paste feature in Markdown, while the ones showing as black flags below were pasted by simply copying them from GPT.

Last edited 14 months ago by kimjiwoon (previous) (diff)

#6 @kimjiwoon
14 months ago

​https://github.com/wordpress-mobile/WordPress-iOS/issues/24551
​https://wordpress.slack.com/archives/C02RQBWTW/p1747561489611609
This is something I posted in the Core channel on Slack about three months ago, and as you can see from the attached file, the issue did exist.
If the bug has been fixed but no one knows why, that in itself seems like a problem.
Moreover, it doesn’t appear to be fully resolved—based on other users’ cases, the issue still seems to persist.
​https://wordpress.slack.com/archives/C02RQBWTW/p1755169123544069?thread_ts=1747561489.611609&cid=C02RQBWTW

Last edited 14 months ago by kimjiwoon (previous) (diff)

This ticket was mentioned in ​Slack in #core by kimjiwoon. ​View the logs.


14 months ago

#8 follow-up: @swissspidy
14 months ago

  • Keywords close added

In WordPress Core Trac, the same flag emojis still render as 🏴 black flags on Windows.

Trac doesn't use Twemoji, so that sounds as expected.

Possibly unrelated, but on WordPress.com the block editor is enabled for comments, and when inserting these emojis there, they are sometimes added as image elements instead of Unicode characters.

It sounds like you were possibly copying a Twemoji image. If it can be reproduced outside of WordPress.com (e.g. in Gutenberg Playground), I suggest opening an issue on Gutenberg. Otherwise, report it to WordPress.com.

#9 in reply to: ↑ 8 @siliconforks
14 months ago

Replying to swissspidy:

Trac doesn't use Twemoji, so that sounds as expected.

Trac does in fact use Twemoji - see the previous discussion here. It might not be loaded in some browsers, though.

#10 @kimjiwoon
3 weeks ago

Following up on my report with what I found in the source, since this looks likely to come back.

The flag support test in emoji-loader.js draws three sequences, and any failure makes flag false: the transgender flag (a ZWJ sequence), the Sark flag, and the England flag (a tag sequence). When flag is false but emoji is true (everythingExceptFlag), wp-emoji.js only replaces what matches this list:

/^1f1(?:e[6-9a-f]|f[0-9a-f])-1f1(?:e[6-9a-f]|f[0-9a-f])$/  // Country flags.
/^(1f3f3-fe0f-200d-1f308|1f3f4-200d-2620-fe0f)$/            // Rainbow and pirate flags.

England, Scotland and Wales are not on it, and neither is the transgender flag. So on a system that fails the flag test only because of those sequences, they are left to a font that cannot draw them, and England shows as a plain black flag. That matches the original report.

Why it stopped reproducing is likely the other test. 6.8.1 tested for Emoji 15.1, and 6.8.2 moved the test to Emoji 16.0. On a system without Emoji 16, emoji is false, WordPress replaces every emoji, and the subdivision flags become Twemoji images along with everything else. That would fit what I described in comment:5 and the replacement seen in comment:4. Since 6.9, #66104 makes emoji false everywhere, which has the same effect.

Once #66104 is fixed, browsers that draw Emoji 17 but not these flags go back to everythingExceptFlag. I reproduced that with the #66104 patch and Core's wp-emoji.js and twemoji.js on a local page in Chromium on Windows: the England flag was not replaced and showed as a black flag, while a country flag on the same page was replaced.

A fix would add the sequences the flag test checks (the subdivision tag sequences, for example 1f3f4-e0067-e0062-e0065-e006e-e0067-e007f for England, and the transgender flag) to the list above. I'd suggest keeping this ticket open, and it may be worth considering alongside #66104.

For wider context: ​Gutenberg discussion #83032.

This ticket was mentioned in ​PR #13581 on ​WordPress/wordpress-develop by ​@kimjiwoon.


3 weeks ago
#11

  • Keywords has-patch has-unit-tests added

When a browser passes the emoji support test but fails the flag test, settings.supports.everythingExceptFlag is true and wp-emoji.js replaces only what matches its flag list: country flags (regional indicator pairs) and the rainbow and pirate flags. The flag test itself checks three sequences, the transgender flag, the Sark flag and the England flag, and the first and last of those are not on the list. So on a system that fails the test because of them, England, Scotland, Wales and the transgender flag are left to a font that cannot draw them; England shows as a plain black flag. That is the report in Core Trac #63451.

This adds the two missing kinds to the list:

  • subdivision flags, as Twemoji passes them to the callback: a black flag, tag characters and a cancel tag (1f3f4-e0067-e0062-e0065-e006e-e0067-e007f for England);
  • the transgender flag, 1f3f3-fe0f-200d-26a7-fe0f.

A black or white flag on its own is not a flag sequence and is still left as text, as before.

The bug is hidden at the moment because Core Trac #66104 makes the emoji test fail in every browser, so everything is replaced. Once Core Trac #66104 is committed, browsers that draw Emoji 17 but not these flags return to everythingExceptFlag, and the report comes back.

Testing: a new QUnit page, tests/qunit/wp-includes/js/emoji-flags.html, loads wp-emoji.js with everythingExceptFlag and checks, through wp.emoji.parse(), that country, England, Scotland, Wales, transgender, rainbow and pirate flags each become one image with the expected code, and that a non-flag emoji and a lone black flag stay text. With trunk's wp-emoji.js, 8 of its 16 assertions fail (England, Scotland, Wales and transgender); with this change all pass. The page is separate from the emoji.html page proposed in #13568 for Core Trac #66120, so the two pull requests do not touch the same test file. jshint passes on both changed scripts.

Use of AI Tools

This pull request was prepared with Claude Code (Anthropic). It read the flag test and replacement list, confirmed the icon codes by running Core's twemoji.js, wrote the fix and the QUnit tests, and ran the tests and lint checks locally.

​@kimjiwoon commented on ​PR #13581:


2 weeks ago
#12

@peterwilsoncc , now that #66104 is fixed in trunk, the everythingExceptFlag
path is no longer masked. This PR covers the restored failure mode for
subdivision and transgender flags. Could you take a look when you have a chance?

Note: See TracTickets for help on using tickets.