1460527 - Using variation selectors to change graphical emoji representation doesn’t work

Status: RESOLVED FIXED

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

Description

[Adolfo Jayme]

+++ This bug was initially created as a clone of Bug #727276 +++

Using variation selectors as in attachment 597200 [details] doesn’t make any visual difference.

Tested under Linux with Nightly 62.0a1 (2018-05-09) (64-bit) and also with 32-bit Nightly under a Windows 7 VM. ← Both versions use the bundled emoji color font from Firefox, instead of relying on the system’s emoji fonts.

Another test page is this [1]: look at the diff section: on the left side you should see colored thumbs-up and thumbs-down symbols; on the right, after applying a variation selector, you should see black-and-white thumbs.

[1] https://wiki.documentfoundation.org/index.php?title=ES/Gu%C3%ADa_de_estilo&diff=prev&oldid=160437

Comment 1

[Adolfo Jayme]

Attachment: Screenshot

Comment 2

[Ian Moody [:Kwan] (UTC+0)]

This seems to have been a regression caused by changing the shipped emoji font.

2018-06-06T18:08:59: DEBUG : Using url: https://hg.mozilla.org/integration/mozilla-inbound/json-pushes?changeset=2b389ab9983995e7bad006f21d28f84878b5d3be&full=1
2018-06-06T18:09:00: DEBUG : Found commit message:
Bug 1358240 - Replace EmojiOne with Twemoji, r=jfkthame, timdream

I was using https://en.wikipedia.org/wiki/Miscellaneous_Symbols_and_Pictographs as a test page.

Comment 3

[Tim Guan-tin Chien [:timdream] (please needinfo)]

We have reftests in place for this feature, I wonder what happened?

https://searchfox.org/mozilla-central/source/layout/reftests/text/reftest.list#198,202-203

:jfkthame would have better ideas about this. I can dig deeper when I have free cycles.

Comment 4

[Ian Moody [:Kwan] (UTC+0)]

Attachment: Unicode 11 Emoji variations

Interestingly it does still work for the heart character in that particular test, (as well as some other emojis), so coincidental character selection.
So it's not that the mechanism doesn't work entirely, just not for certain characters.  Perhaps just errors in the font file?

Using https://www.unicode.org/Public/emoji/11.0/emoji-variation-sequences.txt as a source I've made a file where you can compare all the text and emoji variants to see the extent of the affected ones.

Comment 5

[Ian Moody [:Kwan] (UTC+0)]

Attachment: Test file in Firefox 60

Comment 6

[Ian Moody [:Kwan] (UTC+0)]

Attachment: Test file in Firefox 62

Comment 7

[Ryan VanderMeulen [:RyanVM]]

This is still reproducible for me in an Ubuntu VM on both 61 and 62.

Comment 8

[Ryan VanderMeulen [:RyanVM]]

Not going to track this for 61 at this point, but I'd be open to fixing it in a dot release if it just needs a font update.

Comment 9

[Jonathan Kew [:jfkthame]]

Attachment: Add Symbola to the common fallbacks list on Linux, to reduce the probability of falling back to the color-emoji font when emoji-style rendering is not actually wanted

The issue here is that when a font that supports the relevant characters has not been explicitly listed, and we hit the system-fallback code, there's nothing to prevent us picking the color-emoji font during the fallback process if it happens to support the character. The change from EmojiOne Mozilla to Twemoji Mozilla affected behavior because it changed the iteration order of the global font-family list, and we're now using TwEmoji Mozilla in cases where we previously picked Symbola. To fix this, we can add Symbola to the gfxPlatformGtk list of common fallbacks, so it will take precedence over the emoji font in cases where color-emoji-style rendering was not requested.

Comment 10

[Ryan VanderMeulen [:RyanVM]]

Comment 0 says this affected Win 7 too.

Comment 11

[Jonathan Kew [:jfkthame]]

Yes, I saw that Win7 was mentioned, but haven't had a chance to investigate that yet.

It's not clear to me whether that just means it has always been an issue on Win7, or whether that also regressed with the EmojiOne->Twemoji change. (On Ubuntu, there was a clear change in behavior.)

Adolfo, Ian: can either of you confirm whether the Win7 behavior -changed- in Fx61, or has it always had this issue because of the limited font support there?

Comment 12

[Ian Moody [:Kwan] (UTC+0)]

Attachment: Test file in Firefox 60, Windows 7

Comment 13

[Ian Moody [:Kwan] (UTC+0)]

Attachment: Test file in Firefox 62, Windows 7 (DevEd b1)

Comment 14

[Ian Moody [:Kwan] (UTC+0)]

Attachment: Test file in Firefox 60, Windows 7

Comment 15

[Ian Moody [:Kwan] (UTC+0)]

Man, making me boot-up my battered old Win7 laptop is just mean to it ;)

Anyway, as can be seen in the attached images, Win7 suffers from the same issue, just with slightly different glyphs affected.  Less overall from a quick glance.

Something else I've realised is that the emoji-presentation selector doesn't always work either, and didn't before the Twemoji change.
If I open the testcase and edit the CSS to include 
span + span { font-family: "EmojiOne Mozilla"; }
(or Twemoji Mozilla on 61 and up) I get more colour emojis, most notably the numbers. (Which for some reason are busted in Twemoji, it looks like it might not actually have glyphs for numbers, only numbers plus COMBINING ENCLOSING KEYCAP)

Ignorant question: don't the font files need a format 14 cmap table[1] to properly support variations? They only seem to have 0, 4, and 12.

[1] https://docs.microsoft.com/en-us/typography/opentype/spec/cmap#format-14-unicode-variation-sequences

Comment 16

[Jonathan Kew [:jfkthame]]

(In reply to Ian Moody [:Kwan] (UTC+0) from comment #15)
> Man, making me boot-up my battered old Win7 laptop is just mean to it ;)
> 
> Anyway, as can be seen in the attached images, Win7 suffers from the same
> issue, just with slightly different glyphs affected.  Less overall from a
> quick glance.

OK, that's helpful. One more thing: could you please use the Fonts panel in the Element Inspector to check what font was actually being used by Fx60 for some of the characters that were b/w there, but (incorrectly) appear in color in Fx62? E.g. the STOPWATCH and TIMER CLOCK near the end of the first line in the screenshots. Thanks!

> 
> Something else I've realised is that the emoji-presentation selector doesn't
> always work either, and didn't before the Twemoji change.

Yeah, that's a somewhat different issue, dependent on what the fonts happen to support; I'm not aiming to fix that here.

> If I open the testcase and edit the CSS to include 
> span + span { font-family: "EmojiOne Mozilla"; }
> (or Twemoji Mozilla on 61 and up) I get more colour emojis, most notably the
> numbers. (Which for some reason are busted in Twemoji, it looks like it
> might not actually have glyphs for numbers, only numbers plus COMBINING
> ENCLOSING KEYCAP)
> 
> Ignorant question: don't the font files need a format 14 cmap table[1] to
> properly support variations? They only seem to have 0, 4, and 12.

Not necessarily; it's also possible to support variation selectors via GSUB rules.

But the issue here isn't about support for the variation selectors within the emoji fonts, it's about font selection -- i.e. whether we use the color emoji font or some other available symbol font, when a specific font-family has not been named.

Comment 17

[Makoto Kato [:m_kato]]

Comment on attachment 8986546 [details] [diff] [review]
Add Symbola to the common fallbacks list on Linux, to reduce the probability of falling back to the color-emoji font when emoji-style rendering is not actually wanted

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

Hmm, the latest fontconfig supports emoji family now (bug 1424675), but emoji entry has both color and monochrome on Debian/sid...  I send a feedback to fontconfig dev for a way of getting monochrome emoji font (text presentation).

Comment 18

[Ian Moody [:Kwan] (UTC+0)]

(In reply to Jonathan Kew (:jfkthame) from comment #16)
> (In reply to Ian Moody [:Kwan] (UTC+0) from comment #15)
> > Man, making me boot-up my battered old Win7 laptop is just mean to it ;)
> > 
> > Anyway, as can be seen in the attached images, Win7 suffers from the same
> > issue, just with slightly different glyphs affected.  Less overall from a
> > quick glance.
> 
> OK, that's helpful. One more thing: could you please use the Fonts panel in
> the Element Inspector to check what font was actually being used by Fx60 for
> some of the characters that were b/w there, but (incorrectly) appear in
> color in Fx62? E.g. the STOPWATCH and TIMER CLOCK near the end of the first
> line in the screenshots. Thanks!

Symbola.  Also the same for the several others I checked.
Inspecting the font on <body> in 62 it's now not used at all for anything in the document, since it doesn't appear there.

Comment 19

[Jonathan Kew [:jfkthame]]

(In reply to Ian Moody [:Kwan] (UTC+0) from comment #18)
> > OK, that's helpful. One more thing: could you please use the Fonts panel in
> > the Element Inspector to check what font was actually being used by Fx60 for
> > some of the characters that were b/w there, but (incorrectly) appear in
> > color in Fx62? E.g. the STOPWATCH and TIMER CLOCK near the end of the first
> > line in the screenshots. Thanks!
> 
> Symbola.  Also the same for the several others I checked.

Which platform is that on -- Linux? I intended to ask specifically about Win7, where I don't think Symbola is normally present (unless it has been added by the user), right?

Sorry, I should've been clearer! Can you fire up your Win7 machine and see what Fx60 was using there for those characters? Thanks again!

Comment 20

[Ian Moody [:Kwan] (UTC+0)]

(In reply to Jonathan Kew (:jfkthame) from comment #19)
> (In reply to Ian Moody [:Kwan] (UTC+0) from comment #18)
> > > OK, that's helpful. One more thing: could you please use the Fonts panel in
> > > the Element Inspector to check what font was actually being used by Fx60 for
> > > some of the characters that were b/w there, but (incorrectly) appear in
> > > color in Fx62? E.g. the STOPWATCH and TIMER CLOCK near the end of the first
> > > line in the screenshots. Thanks!
> > 
> > Symbola.  Also the same for the several others I checked.
> 
> Which platform is that on -- Linux? I intended to ask specifically about
> Win7, where I don't think Symbola is normally present (unless it has been
> added by the user), right?
> 
> Sorry, I should've been clearer! Can you fire up your Win7 machine and see
> what Fx60 was using there for those characters? Thanks again!

It's okay, you were perfectly clear, and that result was from Windows 7.
Perhaps I installed it manually at some point then...  at this point I have no recollection, although it's possible inspecting my downloads folder could illuminate.

Comment 21

[Ian Moody [:Kwan] (UTC+0)]

Attachment: Test file in Firefox 60, Windows 7, Symbola font uninstalled

Comment 22

[Ian Moody [:Kwan] (UTC+0)]

Attachment: Test file in Firefox 62, Windows 7 (DevEd b1), SYmbola font uninstalled

While there are no obvious download artifacts for Symbola on my Win7 machine (not even next to the artifacts for a half-dozen other downloaded fonts)  it seems highly likely I would have installed it at some point (the metadata's mention of 'Unicode Font for Ancient Scripts' even seems familiar).
As such I uninstalled the font and retested, and can now see no obvious differences in behaviour between Fx60 and 62 on Win7.

Comment 23

[Jonathan Kew [:jfkthame]]

OK, thanks again. I'm pretty sure Symbola has never been a standard font on Windows.[1] So it doesn't look like there's a significant regression here for Windows in general; fallback behavior did change (similarly to Linux) for you but only because of the additional font that was present.

[1] https://en.wikipedia.org/wiki/List_of_typefaces_included_with_Microsoft_Windows

Comment 24

[Jonathan Kew [:jfkthame]]

(In reply to Jonathan Kew (:jfkthame) from comment #9)
> Created attachment 8986546 [details] [diff] [review]
> Add Symbola to the common fallbacks list on Linux, to reduce the probability
> of falling back to the color-emoji font when emoji-style rendering is not
> actually wanted

Just FTR, it turns out this affects a number of the WPT first-letter reftests, because it changes the font that gets picked during fallback, and perturbs line height. These tests seem to be inherently fragile (a huge number of them are already annotated as failing, although the "failures" are similarly spurious), and really need a systemic fix; meanwhile, I'm just going to update the metadata to note the new failures.

Comment 25

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/fced30d7aa53
Add Symbola to the common fallbacks list on Linux, to reduce the probability of falling back to the color-emoji font when emoji-style rendering is not actually wanted. r=m_kato
https://hg.mozilla.org/integration/mozilla-inbound/rev/cc09d4eeb415
Adjust WPT expectations for font fallback changes that affect fragile first-letter tests. r=me.

Comment 26

[Andreea Pavel [:apavel]]

https://hg.mozilla.org/mozilla-central/rev/fced30d7aa53
https://hg.mozilla.org/mozilla-central/rev/cc09d4eeb415

Comment 27

[Adolfo Jayme]

Attachment: No difference in Nightly 2018-06-23

The patch doesn’t make a difference for me with attachment 597200 [details]. Tested with Nightly 2018-06-23 under Ubuntu.

Comment 28

[Jonathan Kew [:jfkthame]]

I suspect attachment 597200 [details] doesn't work as intended because the linked @font-face resource won't load (check the web console for error messages), and so the Symbola font is unavailable.

Does attachment 8984103 [details] look any better with the latest Nightly for you?

Comment 29

[Ian Moody [:Kwan] (UTC+0)]

Attachment: Test file in Firefox Nightly 62 (2018-06-22) 16a043079689, Ubuntu

Looks fixed to me!

Also as a note, I setup a new Win7 VM to try the testcase in, and there is even less text presentation in that (but still the same result before/after switch to Twemoji), so clearly my laptop is not a good representative for average Win7 font results.

Comment 30

[Jonathan Kew [:jfkthame]]

Comment on attachment 8986546 [details] [diff] [review]
Add Symbola to the common fallbacks list on Linux, to reduce the probability of falling back to the color-emoji font when emoji-style rendering is not actually wanted

Approval Request Comment
[Feature/Bug causing the regression]: bug 1358240
[User impact if declined]: more frequent cases where color emoji-style glyphs are used even though they were not expected
[Is this code covered by automated tests?]: to some extent; it's impractical to test exhaustively because behavior is dependent on the individual system's repertoire of installed fonts
[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]: none
[Is the change risky?]: no
[Why is the change risky/not risky?]: trivial patch just adding a common Symbol font to the list of preferred fallbacks
[String changes made/needed]: none

Comment 31

[Ian Moody [:Kwan] (UTC+0)]

Did you mean beta or release?  I believe 61 has gone to the release repo now, so would require release approval, and the fix already made it to beta/62.

Comment 32

[Jonathan Kew [:jfkthame]]

Ah, so it did... I was forgetting we're in that period leading up to a release when versions across the channels get kinda weird. So, no need for beta uplift; but I guess Ryan might like to consider it for a Fx61 dot-release if one happens. (I don't think the issue is anywhere near serious enough to drive a respin or dot-release itself; but the patch is safe enough to take as a ride-along IMO.)

I'll adjust the flag, and let release-drivers decide what they want to do with it, if anything.

Comment 33

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 8986546 [details] [diff] [review]
Add Symbola to the common fallbacks list on Linux, to reduce the probability of falling back to the color-emoji font when emoji-style rendering is not actually wanted

Approved for 61.0.1.

Comment 34

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-release/rev/42ee22b7ad56