Closed Bug 1866883 Opened 5 months ago Closed 3 months ago

bold emoji is broken

Categories

(Core :: Layout: Text and Fonts, defect, P3)

Firefox 120
Desktop
Windows 11
defect

Tracking

()

VERIFIED FIXED
123 Branch
Tracking Status
firefox-esr115 --- verified
firefox121 --- wontfix
firefox122 --- verified
firefox123 --- verified

People

(Reporter: eyalgruss, Assigned: jfkthame)

References

(Regression, )

Details

(Keywords: regression)

Attachments

(9 files)

Attached image screenshot

example of normal emoji and broken bold version:

🪐 🪐

code:

🪐
<b>&#x1fa90;</b>

in chrome the bold emoji looks the same as the normal weight.
both firefox and chrome are using Segoe UI Emoji font.

Attached file testcase.html

I guess this is Windows 11-specific? On Win10, I don't see the issue; but it has the older COLRv0 Segoe UI Emoji font (the one with bold black outlines), not the COLRv1 font.

Does any color emoji glyph show similar issues with bold, or are only certain glyphs affected?

Flags: needinfo?(jfkthame)

The severity field is not set for this bug.
:tlouw, could you have a look please?

For more information, please visit BugBot documentation.

Flags: needinfo?(tlouw)
Flags: needinfo?(tlouw) → needinfo?(eyalgruss)

i've only seen the issue for this specific emoji, and did not see issues for other colorful emoji's, including from the same block e.g. 🫀 (but i did not do extensive testing)

Flags: needinfo?(eyalgruss)
Keywords: regression
Regressed by: 1740530
Severity: -- → S3
Priority: -- → P3

(In reply to Jonathan Kew [:jfkthame] from comment #3)

I guess this is Windows 11-specific? On Win10, I don't see the issue; but it has the older COLRv0 Segoe UI Emoji font (the one with bold black outlines), not the COLRv1 font.

Confirmed, this is Win11 specific; I can repro in Win11 but not Win10 (using BrowserStack, running Firefox 122 beta).

Also: unsurprisingly, the bug goes away on Win11 if I toggle gfx.font_rendering.colr_v1.enabled to false in about:config. (No restart or even reload needed.)

Does any color emoji glyph show similar issues with bold, or are only certain glyphs affected?

Here's another not-bold/bold comparison testcase, with all the characters listed on https://www.fileformat.info/info/unicode/font/segoe_ui_emoji/list.htm , starting with the first one that has color, which is U+231A WATCH.

This isn't a complete list (it's missing the planet emoji in question here for example, I think, 🪐), but it does have some emoji that show similar glitches in their bold form.

Set release status flags based on info from the regressing bug 1740530

Here are some more glitches from further down testcase 2. The bowling-ball one (at the bottom of this screenshot) has a similar glitch to the one that's shown for the saturn-planet-glyph from comment 0.

jfkthame, is there a way you can tell whether this is just a bug in the font itself? I haven't yet found another program that renders the COLRV1 versions of these glyphs, so I can't tell if this issue is specific to us or not.

Microsoft Word and Chrome seem to render the pre-COLRV1 "flatter-looking" versions of these glyphs (the versions that we render if I turn off gfx.font_rendering.colr_v1.enabled in Firefox). The new/old glyph distinction is easiest to see with U+1F3B3 BOWLING, whose older version is a very flat-looking icon with a thick gray outline, vs. the newer one has 3d shading and doesn't really have an outline (see bottom of comment 12).

Here's the testcase that I'm using when testing other software here, FWIW -- just picking a few of the problematic glyphs screenshotted above:

data:text/html,<meta charset="utf-8"><b>🪐🌚🌜🎳🎾🏀🏁🕐</b>
Flags: needinfo?(jfkthame)

This might just be the known issue discussed in
https://www.reddit.com/r/Windows11/comments/16x7f5g/i_no_longer_have_3d_emojis/

which references this Windows support issue (from September):
https://support.microsoft.com/en-us/topic/september-26-2023-windows-configuration-update-542780c2-594c-46cb-979d-11116fe164ba
Quoting that MS page:

Symptom
The color font format for COLRv1 does not render properly. This format enables Windows to display emoji with a 3D-like appearance.

Workaround
We are working on a resolution and will provide an update in an upcoming release.

It doesn't go into detail about what the rendering issue was, but it seems believable that it was this very issue. Also, if I focus a textarea and use the windows key-command WinKey + . to bring up the OS emoji picker popup, and type e.g. "bowling" into the search field, I see a flat bowling icon with a thick gray outline as I described in my previous comment -- similar to what the person noticed in that reddit page.

So: it looks like maybe Microsoft intended to disable the COLRv1 glyphs, but Firefox isn't seeing then as disabled and is dutifully rendering them, which is kinda-bad (for the broken glyphs) and kinda-good (for using/showing-off the new shiny tech). Maybe we should figure out how/why it's disabled for other apps and consider whether we should respond to that same signal?

This seems to be an issue with the DirectWrite "bold simulation" that it by default uses if a bold font is requested, but no bold face is available in the current font family. This attempts to fatten all the glyph outlines, but we've seen some cases where it gives really poor rendering and so we disable it by default for webfonts (we assume that the system's installed fonts are likely to work OK).

For COLR fonts, each different-colored layer is a separate glyph in the font, and they may be transformed, clipped, etc. in various ways. I guess it's not too surprising that this doesn't play well with applying the bold-simulation to each individual outline. The simplest mitigation here, I think, is to check for the presence of the COLR table and suppress the use of the DirectWrite bold simulation for such faces (like we do for webfonts).

Flags: needinfo?(jfkthame)

The DirectWrite "bold simulation" has poor results with some fonts;
we already disable it by default for webfonts, to avoid rendering
issues.

As it also works poorly with some of the component layers in Segoe UI
Emoji, let's disable it for COLR fonts as well.

Assignee: nobody → jfkthame
Status: NEW → ASSIGNED
Pushed by jkew@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/86b0c45e28ea
Avoid attempting to apply DirectWrite FONT_SIMULATIONS_BOLD to COLR fonts. r=gfx-reviewers,lsalzman
Status: ASSIGNED → RESOLVED
Closed: 3 months ago
Resolution: --- → FIXED
Target Milestone: --- → 123 Branch

The patch landed in nightly and beta is affected.
:jfkthame, is this bug important enough to require an uplift?

  • If yes, please nominate the patch for beta approval.
  • If no, please set status-firefox122 to wontfix.

For more information, please visit BugBot documentation.

Flags: needinfo?(jfkthame)

The DirectWrite "bold simulation" has poor results with some fonts;
we already disable it by default for webfonts, to avoid rendering
issues.

As it also works poorly with some of the component layers in Segoe UI
Emoji, let's disable it for COLR fonts as well.

Original Revision: https://phabricator.services.mozilla.com/D198495

Attachment #9373140 - Flags: approval-mozilla-beta?

Uplift Approval Request

  • Risk associated with taking this patch: minimal
  • String changes made/needed: none
  • Needs manual QE test: yes
  • Steps to reproduce for manual QE testing: Check rendering of testcase from comment 2
  • Is Android affected?: no
  • Code covered by automated testing: no
  • Fix verified in Nightly: no
  • User impact if declined: A few emoji glyphs on Win11 may render poorly
  • Explanation of risk level: Just disables problematic DirectWrite option when using color fonts
Flags: qe-verify+
Flags: needinfo?(jfkthame)
Attachment #9373140 - Flags: approval-mozilla-release?

Uplift Approval Request

  • Risk associated with taking this patch: minimal
  • String changes made/needed: none
  • Needs manual QE test: yes
  • Is Android affected?: no
  • Fix verified in Nightly: no
  • Code covered by automated testing: no
  • Steps to reproduce for manual QE testing: Check rendering of testcase from comment 2
  • Explanation of risk level: Just disables problematic DirectWrite option when using color fonts
  • User impact if declined: A few emoji glyphs on Win11 may render poorly

Comment on attachment 9373140 [details]
Bug 1866883 - Avoid attempting to apply DirectWrite FONT_SIMULATIONS_BOLD to COLR fonts.

Fx122 is now in release, changing the uplift request from beta to release

Attachment #9373140 - Flags: approval-mozilla-beta?
QA Whiteboard: [qa-triaged]

Reproduced the issue with Firefox 122.0a1 (2023-11-27) on Windows 11x64 by using the attached test cases from comment 2 and comment 8. Some emoji are not rendered correctly.
The issue is verified fixed with Firefox 123.0a1 (2024-01-17) on Windows 11x64 by verifying the test case from comment 2 and comment 8. The emojis are rendered correctly. I have also verified this on Windows 10x64, macOS 12 and Ubuntu 20 with Firefox 123.0a1 (2024-01-17) by using test case from comment 2 and the emoji is rendered correctly there as well.

Attachment #9373140 - Flags: approval-mozilla-release? → approval-mozilla-release+

Verified fixed with Firefox 122.0 RC2 (20240118164516) on Windows 11x64. The emojis are rendered correctly in the test cases from comment 2 and comment 8. Also, the testcase from comment 2 looks good on Windows 10x64, macOS 12 and Ubuntu 20.

Has STR: --- → yes
QA Whiteboard: [qa-triaged]
Flags: qe-verify+

Should we take this on ESR also? It grafts cleanly. Please add an approval request if yes.

Flags: needinfo?(jfkthame)

Comment on attachment 9372708 [details]
Bug 1866883 - Avoid attempting to apply DirectWrite FONT_SIMULATIONS_BOLD to COLR fonts. r=#gfx-reviewers

ESR Uplift Approval Request

  • If this is not a sec:{high,crit} bug, please state case for ESR consideration: Cosmetic issue, but visually jarring when it happens; as more people update to Win11, it'll be affecting an ever-increasing number of users
  • User impact if declined: Some Windows 11 emoji have broken rendering when bold is applied
  • Fix Landed on Version: 122
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): Just disables problematic DirectWrite option when using color fonts
Flags: needinfo?(jfkthame)
Attachment #9372708 - Flags: approval-mozilla-esr115?

Comment on attachment 9372708 [details]
Bug 1866883 - Avoid attempting to apply DirectWrite FONT_SIMULATIONS_BOLD to COLR fonts. r=#gfx-reviewers

Approved for 115.8esr.

Attachment #9372708 - Flags: approval-mozilla-esr115? → approval-mozilla-esr115+

Verified fixed with Firefox 115.8.0esr (20240212204114) on Windows 11x64. The emojis are rendered correctly in the test cases from comment 2 and comment 8. Also, the testcase from comment 2 looks good on Windows 10x64, macOS 12 and Ubuntu 22.

Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: