1746795 - Flag emojis and others are displayed in double the size on Windows 10 using Firefox Nightly

Status: VERIFIED FIXED

(Core :: Widget: Win32, defect)

Description

[Stillhart]

Attachment: ch flag emoji bug in bug tracker textarea.JPG

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:97.0) Gecko/20100101 Firefox/97.0

Steps to reproduce:

I open any website. I show or add a more seldom used emoji like the Swiss flag. It can be nearly any other flag and some special emojis. I can not define what makes them special.

Once I paste or write the emoji, the emoji is display at nearly double the size

It is easy to reproduce with this simple text field in which I am writing right now. Please compare what you see to the attached screenshot:

Line 1
🇨🇭Line 2
Line 3

I am using Firefox Nightly 97.0a1 (2021-12-19) (64-bit)
on
Edition Windows 10 Pro
Version 21H2
OS build 19044.1415
Experience Windows Feature Experience Pack 120.2212.3920.0

I do not see this behavior on Firefox 95.0.2 (64-Bit) on the same system.

Actual results:

The emoji is shown too big. About twice the desired size in height and width. It doesn't matter if the emoji is in the content, on a plain new website or even in the window title.

Expected results:

The emoji should have been rendered in the correct font size like other emojis.

Comment 1

[Stillhart]

Attachment: ch bug in bug tracker tab title.JPG

This is how it looks like if I add the Swiss emoji to the title of bugzilla.mozilla.org

Comment 2

[Stillhart]

Attachment: ch bug in bug tracker title source code.JPG

This is how it looks like if I add it to the title source code of bugzilla.mozilla.org

Comment 3

[Stillhart]

Attachment: emojis.wiki flags examples.JPG

This is how the website https://emojis.wiki looks like. Other emojis aren't that big. The united nations flag is especially unusual.

Comment 4

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Widget: Win32' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 5

[Timothy Nikkel (:tnikkel)]

Can you use https://mozilla.github.io/mozregression/ to track down what change caused this?

Comment 6

[Stillhart]

(In reply to Timothy Nikkel (:tnikkel) from comment #5)

Can you use https://mozilla.github.io/mozregression/ to track down what change caused this?

I tried to to use it but it's my first time using the Firefox tooling. I choose build type "opt" but I couldn't easily find out whether this actually matches to Firefox Nightly. Anyway the bug did show up and it came to the following conclusion.

2021-12-20T14:57:03.986000: DEBUG : Found commit message:
Bug 1320197 - Add reftest. r=emilio
Differential Revision: https://phabricator.services.mozilla.com/D133653

Based on the content, I am not really certain if it really matches or makes sense. I assume I am wrong though.
I will add an additional screenshot of mozregression in case I made a mistake one the way.

Additionally I can say that executing mozregression gave security warnings (as expected and documented) and therefore I did run it in the windows sandbox. This should make my test a little bit more clean and reproducible.

Comment 7

[Stillhart]

Attachment: mozregression.JPG

This is how the mozregression gui looked like during the regression search.

Comment 8

[Alice0775 White]

Pushlog from jpg comment#7
https://hg.mozilla.org/integration/autolandhttps://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=55b351f8&tochange=cbfbd2ba

Comment 9

[Timothy Nikkel (:tnikkel)]

Link fixed
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=55b351f8&tochange=cbfbd2ba

Comment 10

[Jonathan Kew [:jfkthame]]

Ugh, that's unfortunate. I'm curious what emoji font is being used there, as that doesn't look like either Segoe UI Emoji (standard Windows font) or Twemoji Mozilla (bundled with Firefox).

Stillhart, do you have other emoji fonts installed.... I'm guessing maybe a version of the EmojiOne font, or its JoyPixels descendant? It would be good to confirm exactly what font is involved here.

Comment 11

[BugBot [:suhaib / :marco/ :calixte]]

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

Comment 12

[Stillhart]

(In reply to Jonathan Kew (:jfkthame) from comment #10)

Ugh, that's unfortunate. I'm curious what emoji font is being used there, as that doesn't look like either Segoe UI Emoji (standard Windows font) or Twemoji Mozilla (bundled with Firefox).

Stillhart, do you have other emoji fonts installed.... I'm guessing maybe a version of the EmojiOne font, or its JoyPixels descendant? It would be good to confirm exactly what font is involved here.

I am not aware that I installed any kind of special emoji font. Of course any other installed application could have done it. I use the basic Windows 10 Emoji menu by pressing <Windows>+<DOT>. This maps to "Segoe UI Emoji". Interestingly it seems like I also have the following font installed: "EmojiOne Color". Both fonts are also present in the Windows Sandbox.

https://github.com/13rac1/emojione-color-font (not sure if this is 100% the same)
https://emojipedia.org/microsoft/windows-10-may-2019-update/
https://docs.microsoft.com/en-us/typography/font-list/segoe-ui-emoji

My Firefox configuration has the following line

font.name-list.emoji Segoe UI Emoji, Twemoji Mozilla

The emojione repo mentions the replacement called Twemoji which is this one:
https://github.com/eosrei/twemoji-color-font
This again maps nicely to the one mentioned in the Firefox configuration: Twemoji Mozilla
https://github.com/mozilla/twemoji-colr
But that is a dead end since I can't see a Swiss flag implementation there.

Luckily I just found out that the Firefox developer Tools have a Font tab. The following 🇨🇭 Swiss flag results in the following "fonts used" in this bugzilla textarea:
FiraGO - FiraGO Book
EmojiOne Color - EmojiOne Color SVGinOT

I am running out of time right now but it can't find any evidence that EmojiOne is a standard system font. I will investigate this further.

Comment 13

[Jonathan Kew [:jfkthame]]

OK, thanks. So it's the EmojiOne Color SVGinOT that is getting scaled incorrectly. It's definitely not a standard Windows system font, so I guess you must have installed it sometime in the past (perhaps as part of installing some other application or package). This must be related to the coordinate system it is using internally; I'll try to look into it.

No need for you to spend more time on this for now, I think -- this should be enough information for us to investigate.

(If you're not concerned about using that particular emoji font, you could try uninstalling it; I think that will result in seeing flags (for example) from Twemoji Mozilla, which should be correctly scaled -- though it may also depend exactly how the page is styled. Segoe UI Emoji doesn't include the flag glyphs, last I checked.)

Comment 14

[Jonathan Kew [:jfkthame]]

Aha - I was able to reproduce this, but only by installing an old version of the EmojiOne Color SVGinOT font. With the most recent version available from https://github.com/13rac1/emojione-color-font/releases, the problem doesn't occur; but using the oldest version there (the "first public release" from February 2016), the scaling problem happens.

I think this was actually a bug in the initial version of the font, but was masked by our bug 1320197 which caused Firefox to ignore the font's unitsPerEm value when rendering. Fixing that bug in Firefox revealed the flaw in the font; but fortunately, it's been fixed in newer releases of the font anyway, so all you need to do is replace the obsolete version of EmojiOne Color SVGinOT with the most recent release, and the problem will go away.

Please let me know if that doesn't resolve the problem you're seeing; according to my testing, it should work fine.

Comment 15

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

This does not only affect website content. Pasting ❌ into the address bar in Nightly also shows it as too large. It's also shown in the inflated size on every (?) website, e.g. Google and Linkedin. Tested with Windows 8.1 and latest Nightly (98.0a1) and Beta (97.0b5).

Comment 16

[Jonathan Kew [:jfkthame]]

(In reply to Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout) from comment #15)

This does not only affect website content. Pasting ❌ into the address bar in Nightly also shows it as too large. It's also shown in the inflated size on every (?) website, e.g. Google and Linkedin. Tested with Windows 8.1 and latest Nightly (98.0a1) and Beta (97.0b5).

Do you have a copy of the EmojiOne Color SVGinOT font installed? If so, what version?

Comment 17

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

Indeed. EmojiOneColor-SVGinOT.ttf 1.3.20160725

Comment 18

[jscher2000]

A concern was raised on Discourse that understanding and fixing this problem will be a challenge for most users.

Is there a way to avoid using this font if the glyph is found in one of the other two fonts (Segoe UI Emoji and/or Twemoji Mozilla)? I'm not clear on the order of priority among Emoji fonts.

Comment 19

[Jonathan Kew [:jfkthame]]

I'm surprised the EmojiOne Color SVGinOT font is being used if not explicitly called-for by style properties (e.g. in the address bar). We can't necessarily avoid websites explicitly using it, but in the address bar I'd have expected to get Twemoji Mozilla or Segoe UI Emoji (though the Windows 8.1 version of that may have a more limited character repertoire).

Sebastian, could you confirm what the font.name-list.emoji pref is set to, just to check if that's a factor here? Thanks.

Comment 20

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

It's the default value: Segoe UI Emoji, Twemoji Mozilla

Comment 21

[Ryan VanderMeulen [:RyanVM]]

Looks like bug 1320197 backs out cleanly from Beta if push comes to shove.

Comment 22

[Jonathan Kew [:jfkthame]]

OK, I see what's happening here; it's a bit of an odd edge-case, but we can handle it better.

The problem arises because the "common fallback fonts" list we try on Windows includes both Segoe UI Emoji and Twemoji Mozilla, in that order:
https://searchfox.org/mozilla-central/rev/a2c26b9b49a521f4be39559ca1ca9c345a237c70/gfx/thebes/gfxWindowsPlatform.cpp#699-705

For the flag characters, Segoe UI Emoji supports the codepoints involved (the "regional indicator" characters), and so gfxPlatformFontList::CommonFontFallback returns it to gfxFontGroup::FindFontForChar as the "common" font to try. However, Segoe UI Emoji doesn't actually provide color-emoji glyphs for the regional indicator sequences; it just renders them as individual (monochrome) letters.

FindFontForChar goes to some pains to try and find the "best" rendering of the text it is given, including honoring emoji- vs text-style presentation. So because the font returned by CommonFontFallback only has text-mode glyphs for the regional indicator codepoints, FindFontForChar continues to search for a better font choice, meaning it proceeds to the "global fallback" stage. And at this stage, the (mis-scaled) EmojiOne font is found first, and because it does satisfy the search for a color-emoji glyph, that's what gets used.

To fix this, we have a couple of options. We could just reorder Segoe UI Emoji and Twemoji Mozilla in the common-fallbacks list, so that Twemoji Mozilla would be the one found by CommonFontFallback. However, that would also mean that we'd be switching the rendering of many emoji characters from the system emoji font, which we currently favor, to Twemoji style. That's not something to do lightly; it'd be a very visible change and would make Firefox look a bit less like a "good Windows citizen".

So instead, what I think we should do is enhance CommonFontFallback similarly to how FindFontForChar works, such that if it is specifically looking for an emoji-style presentation, and finds a font that supports the requested codepoint but does not have a color glyph, it continues to search its list, only returning the monochrome font if it fails to find a color alternative.

Comment 23

[Jonathan Kew [:jfkthame]]

Attachment: Bug 1746795 - Make gfxPlatformFontList::CommonFontFallback honor a preference for emoji presentation when searching its font list, rather than just returning the first match for the codepoint. r=#layout-reviewers

Comment 24

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/e886d6330628
Make gfxPlatformFontList::CommonFontFallback honor a preference for emoji presentation when searching its font list, rather than just returning the first match for the codepoint. r=jwatt

Comment 25

[Noemi Erli[:noemi_erli]]

https://hg.mozilla.org/mozilla-central/rev/e886d6330628

Comment 26

[Jonathan Kew [:jfkthame]]

Comment on attachment 9260377 [details]
Bug 1746795 - Make gfxPlatformFontList::CommonFontFallback honor a preference for emoji presentation when searching its font list, rather than just returning the first match for the codepoint. r=#layout-reviewers

Beta/Release Uplift Approval Request

• User impact if declined: Bad display of some emojis (e.g. flags) for Windows users who have installed an old EmojiOne Color SVGinOT font.
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: On Windows:
• install an old release of the EmojiOne Color SVGinOT font (see comment 14)
• check display of the Swiss-flag in the text of comment 0 here
• check display of flags at https://emojis.wiki/ (compare comment 3)
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Tweak to emoji-font fallback search behavior. No effect for content where the site has explicitly styled emoji with an appropriate font, or for users without extra fonts installed.
• String changes made/needed:

Comment 27

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

Verified fixed with Firefox 98.0a1 20220126065618 on Windows 8.1.

Comment 28

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9260377 [details]
Bug 1746795 - Make gfxPlatformFontList::CommonFontFallback honor a preference for emoji presentation when searching its font list, rather than just returning the first match for the codepoint. r=#layout-reviewers

Approved for 97.0b9.

Comment 29

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-beta/rev/258cab44142b

Comment 30

[Hani Yacoub, Desktop QA]

Verified as fixed on Firefox Nightly 98.0a1 (2022-01-27) on Windows 10 x64.

Comment 31

[Peter Magyari (Desktop QA)]

Verified fixed using Firefox Beta 97.0b9 (20220127193706) on Windows 10.