1360862 - Huge Google Noto emojis since recent Firefox update

Status: RESOLVED FIXED

(Core :: Graphics: Text, defect, P3)

Description

[janxjcl]

Attachment: Screenshot from 2017-04-29 19-56-53.png

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:53.0) Gecko/20100101 Firefox/53.0
Build ID: 20170421105455

Steps to reproduce:

Specs:

- Linux Mint 18 Cinnamon
- Mozilla Firefox 53.0
- emojis via [Google Noto Fonts](https://www.google.com/get/noto/)

Further info:

- !! This behavious started about a week ago, so it was likely introduced in FF 53 and not present in FF 52
- able to reproduce it in Nightly (55.0a1)
- able to reproduce it in a new profile
- able to reproduce it in Linux Mint 17.3 Cinnamon
- affects only Noto emojis in Firefox, not Chromium (else I wouldn't be posting this here!)
- affects only Noto emojis, not Firefox's Emoji One emojis or websites that use their own emojis (Telegram, Discord, ...)

I already joked about this on reddit: https://www.reddit.com/r/firefox/comments/685et1/the_last_update_made_my_emojis_huge/



Actual results:

Huge Noto emojis


Expected results:

Normal-sized Noto emojis

Comment 1

[Jonathan Kew [:jfkthame]]

A regression range (using http://mozilla.github.io/mozregression/) to pinpoint exactly when this broken on Nightly would be useful here.

Comment 2

[janxjcl]

Ah!! I read the hint about mozregression but didn't understand what it was!! Thanks, this is a very useful tool!

Huge emojis start appearing after this bitmap-font-related commit: https://hg.mozilla.org/mozilla-central/rev/a02a2c5c7004

This bug has the changes: https://bugzilla.mozilla.org/show_bug.cgi?id=1350783

Last good revision: 7abe37fae43f1a35fd396def2d7d428374e4e7ec
First bad revision: a02a2c5c7004b45ffe1ef180929b0cbad3e3edd3

Comment 3

[janxjcl]

Perhaps I should include information on how to install Noto emoji? I'm not entirely sure but I think it went like this:

1. Download the font from https://noto-website.storage.googleapis.com/pkgs/NotoColorEmoji-unhinted.zip 
2. Extract it ("NotoColorEmoji.ttf") into ~/.fonts
3. Create a file "/etc/fonts/conf.d/01-notosans.conf" with these contents:

"<?xml version="1.0" ?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<fontconfig>
  <match target="scan">
    <test name="family">
      <string>Noto Color Emoji</string>
    </test>
    <edit name="scalable" mode="assign">
      <bool>true</bool>
    </edit>
  </match>

  <match target="pattern">
    <test name="prgname">
      <string>firefox</string>
    </test>
    <edit name="family" mode="prepend_first">
      <string>Noto Color Emoji</string>
    </edit>
  </match>
</fontconfig>"

4. Run "fc-cache -f -v"
5. (Re)start Firefox

Comment 4

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Maybe related to bug 1267909?  (I'm not sure if that's still around, since I uninstalled Noto Color Emoji now that we're shipping our own emoji font that works better.)

Comment 5

[Lee Salzman [:lsalzman]]

(In reply to David Baron :dbaron: ⌚️UTC-7 from comment #4)
> Maybe related to bug 1267909?  (I'm not sure if that's still around, since I
> uninstalled Noto Color Emoji now that we're shipping our own emoji font that
> works better.)

Sounds plausibly related since the changes I made to enable bitmap fonts on Linux also cleaned up the size selection when multiple bitmap sizes were available. I'm still just starting to dig into this to figure out what's going on, but I suppose any related ammunition helps.

Comment 6

[Lee Salzman [:lsalzman]]

Okay, on further investigation I was able to reproduce this with the config given. However, the problem appears to actually be the config itself.

Overring the scalable attribute is very bad juju. If your config tells us a font is scalable, when it is actually a bitmap font, we skip the internal size selection code that will avoid this very scaling problem for bitmap fonts.

janxjcl, if you just remove the part of your config where you assign the scalable value to true, does it work fine again?

Comment 7

[janxjcl]

After removing the `scalable=true` part and running `fc-cache -f -v` and restarting Firefox the emojis remain huge. If I replace `true` with `false` it doesn't display any emojis at all (with nothing, not even tofus, in their place, ie they're essentially zero-width)

Pardon my ignorance, but why do bitmap fonts play into this anyway? `NotoColorEmoji` is a TrueType font, isn't that entirely separate?

Comment 8

[Lee Salzman [:lsalzman]]

(In reply to janxjcl from comment #7)
> After removing the `scalable=true` part and running `fc-cache -f -v` and
> restarting Firefox the emojis remain huge. If I replace `true` with `false`
> it doesn't display any emojis at all (with nothing, not even tofus, in their
> place, ie they're essentially zero-width)
> 
> Pardon my ignorance, but why do bitmap fonts play into this anyway?
> `NotoColorEmoji` is a TrueType font, isn't that entirely separate?

Because the Noto Color Emoji font relies upon embedded bitmaps. Setting it to scalable is going to screw things up. If you're still seeing huge emoji even when the scalable=true bit is removed, then I am pretty sure you have another config lying around somewhere that is forcing it to scalable=true.

Comment 9

[Jonathan Kew [:jfkthame]]

(In reply to Lee Salzman [:lsalzman] from comment #8)
> (In reply to janxjcl from comment #7)
> > After removing the `scalable=true` part and running `fc-cache -f -v` and
> > restarting Firefox the emojis remain huge. If I replace `true` with `false`
> > it doesn't display any emojis at all (with nothing, not even tofus, in their
> > place, ie they're essentially zero-width)
> > 
> > Pardon my ignorance, but why do bitmap fonts play into this anyway?
> > `NotoColorEmoji` is a TrueType font, isn't that entirely separate?
> 
> Because the Noto Color Emoji font relies upon embedded bitmaps. Setting it
> to scalable is going to screw things up. If you're still seeing huge emoji
> even when the scalable=true bit is removed, then I am pretty sure you have
> another config lying around somewhere that is forcing it to scalable=true.

No, I believe fontconfig treats 'sfnt' resources with embedded color bitmaps as scalable by default (unlike legacy b/w font formats). See https://bugs.freedesktop.org/show_bug.cgi?id=87122.

Comment 10

[Lee Salzman [:lsalzman]]

(In reply to Jonathan Kew (:jfkthame) from comment #9)
> (In reply to Lee Salzman [:lsalzman] from comment #8)
> > (In reply to janxjcl from comment #7)
> > > After removing the `scalable=true` part and running `fc-cache -f -v` and
> > > restarting Firefox the emojis remain huge. If I replace `true` with `false`
> > > it doesn't display any emojis at all (with nothing, not even tofus, in their
> > > place, ie they're essentially zero-width)
> > > 
> > > Pardon my ignorance, but why do bitmap fonts play into this anyway?
> > > `NotoColorEmoji` is a TrueType font, isn't that entirely separate?
> > 
> > Because the Noto Color Emoji font relies upon embedded bitmaps. Setting it
> > to scalable is going to screw things up. If you're still seeing huge emoji
> > even when the scalable=true bit is removed, then I am pretty sure you have
> > another config lying around somewhere that is forcing it to scalable=true.
> 
> No, I believe fontconfig treats 'sfnt' resources with embedded color bitmaps
> as scalable by default (unlike legacy b/w font formats). See
> https://bugs.freedesktop.org/show_bug.cgi?id=87122.

Le sigh. I guess we need to be checking FC_OUTLINE then in this case.

Comment 11

[Lee Salzman [:lsalzman]]

Attachment: use FC_OUTLINE instead of FC_SCALABLE with Fontconfig to check if a font is scalable

Comment 12

[Lee Salzman [:lsalzman]]

(In reply to Lee Salzman [:lsalzman] from comment #10)
> (In reply to Jonathan Kew (:jfkthame) from comment #9)
> > (In reply to Lee Salzman [:lsalzman] from comment #8)
> > > (In reply to janxjcl from comment #7)
> > > > After removing the `scalable=true` part and running `fc-cache -f -v` and
> > > > restarting Firefox the emojis remain huge. If I replace `true` with `false`
> > > > it doesn't display any emojis at all (with nothing, not even tofus, in their
> > > > place, ie they're essentially zero-width)
> > > > 
> > > > Pardon my ignorance, but why do bitmap fonts play into this anyway?
> > > > `NotoColorEmoji` is a TrueType font, isn't that entirely separate?
> > > 
> > > Because the Noto Color Emoji font relies upon embedded bitmaps. Setting it
> > > to scalable is going to screw things up. If you're still seeing huge emoji
> > > even when the scalable=true bit is removed, then I am pretty sure you have
> > > another config lying around somewhere that is forcing it to scalable=true.
> > 
> > No, I believe fontconfig treats 'sfnt' resources with embedded color bitmaps
> > as scalable by default (unlike legacy b/w font formats). See
> > https://bugs.freedesktop.org/show_bug.cgi?id=87122.
> 
> Le sigh. I guess we need to be checking FC_OUTLINE then in this case.

Would also appear that the reason removing the scalable=true part worked for me is because my particular version of fontconfig (2.11.0) does not appear to have that FC_COLOR hack that necessitated the use of FC_OUTLINE. :(

Comment 13

[janxjcl]

Is a different check for scalability going to fix this though? As I stated above, explicitly declaring scalable=false didn't fix the issue but made emojis disappear altogether.

Comment 14

[Lee Salzman [:lsalzman]]

(In reply to janxjcl from comment #13)
> Is a different check for scalability going to fix this though? As I stated
> above, explicitly declaring scalable=false didn't fix the issue but made
> emojis disappear altogether.

This change is required regardless of the situation, since checking for FC_SCALABLE is no longer reliable as per the freedesktop bug description. Forcing scalable to true, screws with the code as it is. Checking for FC_OUTLINE instead avoids cases where people are setting scalable to true to bypass the rejection mechanism.

The reason scalable=false makes the emoji disappear is most likely because there is a fontconfig rule that is rejecting bitmap fonts. At least on Debian, I have a /etc/fonts/conf.d/70-no-bitmaps.conf that does just that, looks for scalable=false and prevents such fonts from even loading. At least I noticed running into this locally, and removing that file was the only way around it.

Also, we sort fonts internally based on whether they are scalable or not, so scalable fonts get priority over non-scalable ones. 

I am reasonably confident that just checking FC_OUTLINE here will sort out this entire rat's nest of issues.

Comment 15

[janxjcl]

So having the 70-no-bitmaps.conf file removed and scalable=false should theoretically fix the issue for me yes? Because it doesn't, I only see tofu:

         | <removed> | 70-no-bitmaps.conf
---------------------------------------------
firefox  |   tofu    |      huge emojis
chromium |   tofu    |  normal-sized emojis

(When I say tofu I mean the boxes shown when it can't display an emoji, they only look like tofu on chromium and like rectangles with hex numbers in them in firefox)

Comment 16

[Lee Salzman [:lsalzman]]

(In reply to janxjcl from comment #15)
> So having the 70-no-bitmaps.conf file removed and scalable=false should
> theoretically fix the issue for me yes? Because it doesn't, I only see tofu:
> 
>          | <removed> | 70-no-bitmaps.conf
> ---------------------------------------------
> firefox  |   tofu    |      huge emojis
> chromium |   tofu    |  normal-sized emojis
> 
> (When I say tofu I mean the boxes shown when it can't display an emoji, they
> only look like tofu on chromium and like rectangles with hex numbers in them
> in firefox)

No, that won't fix it because we still sort fonts based on scalable attribute internally, so that scalable fonts get preference. The only way to defuse the situation is my patch that checks FC_OUTLINE instead... Jonathan, can you please review?

Comment 17

[Jonathan Kew [:jfkthame]]

Comment on attachment 8863483 [details] [diff] [review]
use FC_OUTLINE instead of FC_SCALABLE with Fontconfig to check if a font is scalable

Review of attachment 8863483 [details] [diff] [review]:
-----------------------------------------------------------------

I haven't had a chance to test this locally across various configurations, but it seems to make sense; let's go ahead and try it.

Comment 18

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/37a36d779f83
use FC_OUTLINE instead of FC_SCALABLE with Fontconfig to check if a font is scalable. r=jfkthame

Comment 19

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/37a36d779f83

Comment 20

[Lee Salzman [:lsalzman]]

Is the issue fixed if you use the latest nightly? https://download.mozilla.org/?product=firefox-nightly-latest-ssl&os=linux64&lang=en-US

Comment 21

[Jan Alexander Steffens [:heftig]]

https://hg.mozilla.org/mozilla-unified/rev/4a6a71f4aa22 has giant system emoji, https://hg.mozilla.org/mozilla-unified/rev/0b255199db9d doesn't load any system emoji at all, not even the colorless "Noto Emoji", using EmojiOne Mozilla instead.

The current official nightly https://hg.mozilla.org/mozilla-central/rev/33b92d9c4056 behaves like 0b255199db9d.

Arch Linux x86_64, fontconfig 2.12.1.

Comment 22

[Lee Salzman [:lsalzman]]

(In reply to Jan Steffens from comment #21)
> https://hg.mozilla.org/mozilla-unified/rev/4a6a71f4aa22 has giant system
> emoji, https://hg.mozilla.org/mozilla-unified/rev/0b255199db9d doesn't load
> any system emoji at all, not even the colorless "Noto Emoji", using EmojiOne
> Mozilla instead.
> 
> The current official nightly
> https://hg.mozilla.org/mozilla-central/rev/33b92d9c4056 behaves like
> 0b255199db9d.
> 
> Arch Linux x86_64, fontconfig 2.12.1.

Make sure you do not have any scalable=whatever configs lying around.

Comment 23

[Lee Salzman [:lsalzman]]

(In reply to Lee Salzman [:lsalzman] from comment #22)
> (In reply to Jan Steffens from comment #21)
> > https://hg.mozilla.org/mozilla-unified/rev/4a6a71f4aa22 has giant system
> > emoji, https://hg.mozilla.org/mozilla-unified/rev/0b255199db9d doesn't load
> > any system emoji at all, not even the colorless "Noto Emoji", using EmojiOne
> > Mozilla instead.
> > 
> > The current official nightly
> > https://hg.mozilla.org/mozilla-central/rev/33b92d9c4056 behaves like
> > 0b255199db9d.
> > 
> > Arch Linux x86_64, fontconfig 2.12.1.
> 
> Make sure you do not have any scalable=whatever configs lying around.

Should also be noted that if you're using non-colored bitmap fonts, then Firefox will always preferentially use available scalable ones over it due to font sorting (i.e. it will of course use EmojiOne which is scalable). This bug is not about that behavior, so let's please not mix symptoms up, as this bug only concerned colored fonts.

Comment 24

[Jan Alexander Steffens [:heftig]]

(In reply to Lee Salzman [:lsalzman] from comment #22)
> Make sure you do not have any scalable=whatever configs lying around.

There are no configs setting the scalable property.

(In reply to Lee Salzman [:lsalzman] from comment #23)
> Should also be noted that if you're using non-colored bitmap fonts, then
> Firefox will always preferentially use available scalable ones over it due
> to font sorting (i.e. it will of course use EmojiOne which is scalable).
> This bug is not about that behavior, so let's please not mix symptoms up, as
> this bug only concerned colored fonts.

I've tried (properties determined by fc-scan)
   
    "Emoji One" (emojione-android.ttf, CBDT, outline: False, scalable: True, color: True),
    "Noto Color Emoji" (NotoColorEmoji.ttf, CBDT, outline: False, scalable: True, color: True),
    "Apple Color Emoji" (Apple Color Emoji.ttf, sbix, outline: False, scalable: True, color: True),
    "Noto Emoji" (NotoEmoji-Regular.ttf, no bitmaps, outline: True, scalable: True, color: False),

all without success with the slightly smiling face emoji (

Comment 25

[Jan Alexander Steffens [:heftig]]

Argh; Bugzilla trucated my comment at the emoji. Here's it again:


(In reply to Lee Salzman [:lsalzman] from comment #22)
> Make sure you do not have any scalable=whatever configs lying around.

There are no configs setting the scalable property.

(In reply to Lee Salzman [:lsalzman] from comment #23)
> Should also be noted that if you're using non-colored bitmap fonts, then
> Firefox will always preferentially use available scalable ones over it due
> to font sorting (i.e. it will of course use EmojiOne which is scalable).
> This bug is not about that behavior, so let's please not mix symptoms up, as
> this bug only concerned colored fonts.

I've tried (properties determined by fc-scan)
   
    "Emoji One" (emojione-android.ttf, CBDT, outline: False, scalable: True, color: True),
    "Noto Color Emoji" (NotoColorEmoji.ttf, CBDT, outline: False, scalable: True, color: True),
    "Apple Color Emoji" (Apple Color Emoji.ttf, sbix, outline: False, scalable: True, color: True),
    "Noto Emoji" (NotoEmoji-Regular.ttf, no bitmaps, outline: True, scalable: True, color: False),

all without success with the slightly smiling face emoji (u+1f642) and checking the Fonts panel in the inspector.
It consistently used the embedded

    "EmojiOne Mozilla" (EmojiOneMozilla.ttf, COLR, outline: True, scalable: True, color: False).

Now I've retested with the family emoji (u+1f46a), and that one does get loaded from the "Noto Emoji" font, but not any of the others.

Comment 26

[Lee Salzman [:lsalzman]]

(In reply to Jan Steffens from comment #25)
> Argh; Bugzilla trucated my comment at the emoji. Here's it again:
> 
> 
> (In reply to Lee Salzman [:lsalzman] from comment #22)
> > Make sure you do not have any scalable=whatever configs lying around.
> 
> There are no configs setting the scalable property.
> 
> (In reply to Lee Salzman [:lsalzman] from comment #23)
> > Should also be noted that if you're using non-colored bitmap fonts, then
> > Firefox will always preferentially use available scalable ones over it due
> > to font sorting (i.e. it will of course use EmojiOne which is scalable).
> > This bug is not about that behavior, so let's please not mix symptoms up, as
> > this bug only concerned colored fonts.
> 
> I've tried (properties determined by fc-scan)
>    
>     "Emoji One" (emojione-android.ttf, CBDT, outline: False, scalable: True,
> color: True),
>     "Noto Color Emoji" (NotoColorEmoji.ttf, CBDT, outline: False, scalable:
> True, color: True),
>     "Apple Color Emoji" (Apple Color Emoji.ttf, sbix, outline: False,
> scalable: True, color: True),
>     "Noto Emoji" (NotoEmoji-Regular.ttf, no bitmaps, outline: True,
> scalable: True, color: False),
> 
> all without success with the slightly smiling face emoji (u+1f642) and
> checking the Fonts panel in the inspector.
> It consistently used the embedded
> 
>     "EmojiOne Mozilla" (EmojiOneMozilla.ttf, COLR, outline: True, scalable:
> True, color: False).
> 
> Now I've retested with the family emoji (u+1f46a), and that one does get
> loaded from the "Noto Emoji" font, but not any of the others.

That is because those are not outline fonts. So when the 20% size tolerance check (as required by CSS Fonts 3) between the requested size and the fixed size faces fails, it throws out those fonts. Noto Emoji passes because it is an actual outline font with no bitmaps, so it will always pass the size threshold check.

But I think the CSS Fonts 3 spec allows wiggle room here as it specifies the tolerance only applies to non-scalable fonts. Noto Color Emoji, for instance, only supplies a single set of 109 sized bitmaps, presumably with the intention of always being scaled down to fit.

Jonathan, I am guessing what we really want to do here is consider BOTH outline-ness and scalability. If it is not outline, but it is scalable, we want to choose the closest size to the requested size, but NOT apply the size threshold check to it. This should theoretically let these fonts work (according to my local hacks), and still more or less adhere to the spec?

An interesting data point is that I tested Noto Color Emoji with the old pango font code, and it was also oversized emojipasta, meaning it never worked there either. We're treading new and improved functionality grounds here, rejoice!

Comment 27

[Lee Salzman [:lsalzman]]

Attachment: allow bitmap fonts to force scaling and bypass tolerance check in gfxFcPlatformFontList

This patch, as described above, checks FC_OUTLINE and FC_SCALABLE together to determine appropriate behavior. If FC_OUTLINE is false, it still looks among the available fixed sizes and chooses the best one, but ultimately defers to FC_SCALABLE to decide whether to either adhere to the 20% tolerance and not scale, or bypass the tolerance and do scaling. This way, fonts like Noto Color Emoji, that only provide one supersampled fixed-size face, with the intention to scale down... actually work.

With this in place, Noto Color Emoji finally seems to do The Right Thing without deferring to our Emoji One font.

Comment 28

[Jonathan Kew [:jfkthame]]

Comment on attachment 8864945 [details] [diff] [review]
allow bitmap fonts to force scaling and bypass tolerance check in gfxFcPlatformFontList

Review of attachment 8864945 [details] [diff] [review]:
-----------------------------------------------------------------

Makes sense to me; I'll defer to your actual testing to confirm that it provides reasonable behavior.

Comment 29

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/dd650c37854b
allow bitmap fonts to force scaling and bypass tolerance check in gfxFcPlatformFontList. r=jfkthame

Comment 30

[janxjcl]

(In reply to Lee Salzman [:lsalzman] from comment #27)
> With this in place, Noto Color Emoji finally seems to do The Right Thing
> without deferring to our Emoji One font.

Nope. Defers to the Emoji One font in https://archive.mozilla.org/pub/firefox/nightly/2017/05/2017-05-07-10-02-39-mozilla-central/firefox-55.0a1.en-US.linux-x86_64.tar.bz2

Comment 31

[Lee Salzman [:lsalzman]]

(In reply to janxjcl from comment #30)
> (In reply to Lee Salzman [:lsalzman] from comment #27)
> > With this in place, Noto Color Emoji finally seems to do The Right Thing
> > without deferring to our Emoji One font.
> 
> Nope. Defers to the Emoji One font in
> https://archive.mozilla.org/pub/firefox/nightly/2017/05/2017-05-07-10-02-39-
> mozilla-central/firefox-55.0a1.en-US.linux-x86_64.tar.bz2

Did you make sure to remove all the mucking around with the scalable value? It works fine here for me. I would suspect there is something you are missing.

Comment 32

[janxjcl]

I've tried
- with scalable=true
- with scalable=false
- without setting scalable
- without config file entirely

and in all 4 cases it defers to Emoji One, using mozregression for the same build as above. If I use the build from 2017-05-01 without config file I get huge Noto emoji.

Comment 33

[Jan Alexander Steffens [:heftig]]

(In reply to janxjcl from comment #30)
> (In reply to Lee Salzman [:lsalzman] from comment #27)
> > With this in place, Noto Color Emoji finally seems to do The Right Thing
> > without deferring to our Emoji One font.
> 
> Nope. Defers to the Emoji One font in
> https://archive.mozilla.org/pub/firefox/nightly/2017/05/2017-05-07-10-02-39-
> mozilla-central/firefox-55.0a1.en-US.linux-x86_64.tar.bz2

I'm pretty sure this build doesn't have the patch.

Comment 34

[Iris Hsiao [:ihsiao]]

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

Comment 35

[Ryan VanderMeulen [:RyanVM]]

Can we create an automated test that would have caught this regression? Also sounds like we'll be wanting branch approval requests.

Comment 36

[Gerry Chang [:gchang]]

Hi janxjcl,
Can you help check if the issue is fixed in the latest nightly?

Comment 37

[janxjcl]

Attachment: how it looks after being fixed

Seems completely resolved now, thanks

Comment 38

[janxjcl]

Note there are still issues with Noto emojis in firefox tho (screenshot)
1. some line-heights way too high (top) (this is bug 1267909) 
2. numbers aren't in their boxes, except "10" (3/4 of the way down) (unreported?)
3. monochrome font instead of Noto for some emojis (top) (supposedly resolved by my config file due to https://github.com/googlei18n/noto-emoji/issues/36 however problem persists in firefox)

Comment 39

[Jan Alexander Steffens [:heftig]]

(In reply to janxjcl from comment #38)
> Note there are still issues with Noto emojis in firefox tho (screenshot)
> 1. some line-heights way too high (top) (this is bug 1267909) 
> 2. numbers aren't in their boxes, except "10" (3/4 of the way down)
> (unreported?)
> 3. monochrome font instead of Noto for some emojis (top) (supposedly
> resolved by my config file due to
> https://github.com/googlei18n/noto-emoji/issues/36 however problem persists
> in firefox)

Ditto here.

(1) affects 'Emoji One' and 'Noto Color Emoji' but not 'EmojiOne Mozilla' and 'Apple Color Emoji'.
(2) affects all emoji fonts iff a non-emoji font is preferred.
(3) seems to be due to emoji glyphs in preferred fonts, such as 'Noto Sans Symbols' and 'DejaVu Sans'.

So 2 and 3 seem to be the same issue: glyphs from non-emoji fonts either completely replacing color emoji (3) or preventing the emoji ligatures from working (2). However, I think this is working as designed...

Comment 40

[Lee Salzman [:lsalzman]]

(In reply to Ryan VanderMeulen [:RyanVM] from comment #35)
> Can we create an automated test that would have caught this regression? Also
> sounds like we'll be wanting branch approval requests.

This is a bit of a bother to test in so far as it partially depends on Fontconfig behavior. Maybe something could be done using a Webfont, but ideally that would require some small bitmapped/color emoji font that we'd have to shove in the tree to test scaling issues with. So, technically possible yes, but annoying.

Regarding uplift, I've verified at least in bug 1267909 that the positioning issues were an independent bug from the scaling issues here, so I believe it should be safe to uplift this part now.

Comment 41

[Lee Salzman [:lsalzman]]

Comment on attachment 8864945 [details] [diff] [review]
allow bitmap fonts to force scaling and bypass tolerance check in gfxFcPlatformFontList

Approval Request Comment
[Feature/Bug causing the regression]: bug 1350783 exposed this issue to a wider population of users, though isn't necessarily causative.
[User impact if declined]: Third-party color emoji fonts may fail to render or be improperly scaled.
[Is this code covered by automated tests?]: no
[Has the fix been verified in Nightly?]: yes
[Needs manual test from QE? If yes, steps to reproduce]: no 
[List of other uplifts needed for the feature/fix]: Need to uplift both patches in this bug.
[Is the change risky?]: low risk
[Why is the change risky/not risky?]: Linux only. Only affects bitmap color fonts, which are basically just third-party emoji fonts. Most users are just using Mozilla's built-in Emoji One which is not bitmapped and unaffected by this.
[String changes made/needed]: none

Comment 42

[Gerry Chang [:gchang]]

Comment on attachment 8864945 [details] [diff] [review]
allow bitmap fonts to force scaling and bypass tolerance check in gfxFcPlatformFontList

Fix a third-party color emoji fonts rendering issue and was verified. Beta54+. Should be in 54 beta 7.

Comment 43

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-beta/rev/e2ea85498780

Comment 44

[Julien Cristau [:jcristau] (back April 22)]

Comment on attachment 8864945 [details] [diff] [review]
allow bitmap fonts to force scaling and bypass tolerance check in gfxFcPlatformFontList

that doesn't seem to match criteria for esr, esr52-