Open Bug 1922781 Opened 1 year ago Updated 2 months ago

fonts.google.com - Some emojis are not displayed correctly

Categories

(Web Compatibility :: Site Reports, defect, P3)

Product:
Web Compatibility
Component:
Site Reports
Version:
Firefox 133
Platform:
Desktop
Windows 10
Type:
defect

Tracking

(Webcompat Score:1, Webcompat Priority:P3, firefox131 affected, firefox133 affected)

Project Flags:
Webcompat Score 1
Webcompat Priority P3
Tracking Flags:
Tracking Status
firefox131 --- affected
firefox133 --- affected

People

(Reporter: ctanase, Unassigned)

References

(
URL
)

Details

(Keywords: webcompat:needs-diagnosis, webcompat:site-report, Whiteboard: [webcompat-source:web-bugs])

User Story

platform:windows,mac,linux,android
impact:minor-visual
configuration:general
affects:all
branch:release
diagnosis-team:webcompat
user-impact-score:10

Attachments

(1 file)

image.png
376.95 KB, image/png
Details

Environment:
Operating system: Linux/Windows 10
Firefox version: Firefox 130.0/131/133

Preconditions:

  • Clean profile

Steps to reproduce:

  1. Go to https://fonts.google.com/noto/specimen/Noto+Emoji
  2. Observe the font preview.

Expected Behavior:
All emojis are in specific style and black & white.

Actual Behavior:
Some emojis have different style and are colored.

Notes:

  • Reproduces regardless of the status of ETP
  • Reproduces in Firefox Nightly, and Firefox Release
  • Does not reproduce in Chrome

Created from https://github.com/webcompat/web-bugs/issues/142151

Attached image image.png —
status-firefox131: --- → affected
status-firefox133: --- → affected
See Also: → https://github.com/googlefonts/noto-emoji/issues/391, 1767842, 1461589
Version: unspecified → Firefox 133

This specific Google Font doesn't support the emoji in question, so we're falling back to the default font for emojis. Seems like Firefox is picking a different fallback font.

Severity: -- → S4
User Story: (updated)
Keywords: webcompat:needs-diagnosis
Priority: -- → P3

This has been discussed for quite some time in the github page for the font in question, and seems to be a matter of browsers ignoring the desired monochrome glyphs due to their (intentional) lack of a COLR table.

The effected emoji seem to all be sequences that rely on the codepoint for an old-style unicode text symbol, which is combined with the U+FE0F "Emoji-style Variation Selector" modifier to "upgrade" it to a color emoji. The browser currently assumes that any such emoji sequence requires a glyph with a COLR table, and if a font does not have one for that glyph, the browser bypasses it for a font which does.

This effectively breaks all B/W emojji fonts (which lack COLR tables), with no workaround.

Reference: https://github.com/googlefonts/noto-emoji/issues/391

Webcompat Priority: --- → P3
Webcompat Score: --- → 2
Webcompat Score: 2 → 1
User Story: (updated)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: