1567178 - Old black Windows 10 emojis are only displayed correctly when following colored ones

Status: RESOLVED FIXED

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

Description

[Malus]

Attachment: Emoji bug example

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

Steps to reproduce:

On a website, I found text using several eye emojis (👁) with another emoji in between (see the example website in the attachments)

Actual results:

The first eye emoji, which is an emoji left as black in the initial Windows 10 emoji version (see https://emojipedia.org/microsoft/windows-10/), in fact any emoji which wasn't colored yet in this version, is rendered as the black Windows 10 version. However, when inserting another emoji, any emoji which has already been a colored version in the initial Windows 10 version, the eye emoji suddenly becomes colored, as in the Windows 10 Anniversary Update version and after (see https://emojipedia.org/microsoft/windows-10-anniversary-update/).
This happens everywhere where no Emoji font, like Segoe UI Emoji, is set - therefore also in a URL, in the title, etc. (as the example shows).

Expected results:

All emojis should be rendered according to the latest Windows update, or at least rendered uniformly. I don't know much about Unicode and how emojis in browsers work in regard to the OS, but I thought that this behavior is maybe a little weird.

Comment 1

[Malus]

Attachment: Example screenshot

Comment 2

[Luciana queirolo]

Hi,
I wasn't able to reproduce this issue on Nightly 70.0a1 (2019-07-23) and on 68.0
Also, Could you please try to see if it's reproducible on Nightly? here is the link for download https://www.mozilla.org/en-US/firefox/nightly/all/

Thanks!

Comment 3

[Malus]

Nothing has changed between versions - tested it on the latest nightly (70.0a1) and on release 68 and beta 69.0b6.
A friend of mine also has the same problem, so it seems that I am not alone

Comment 4

[ovidiu boca[:Ovidiu]]

Retested again with Win 10 and Mac OS 10.14 with FF Nightly 70.0a1(2019-08-06), FF Beta 69.0b11 and FF Release 68 and I can reproduce it.

Comment 5

[Dzmitry Malyshau [:kvark]]

Lee, let me know if the P3 here is not correct.

Comment 6

[Jonathan Kew [:jfkthame]]

This is about font selection rather than rendering, so moving to Layout. It's probably largely the same issue as bug 1371386; marking as dependent for now.

Comment 7

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

The component has been changed since the backlog priority was decided, so we're resetting it.
For more information, please visit auto_nag documentation.

Comment 8

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

The priority flag is not set for this bug.
:dholbert, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 9

[Hanabishi]

I can confirm this. Also can confirm this is font priority issue.
Because:

And if you forcing the right font via css:

Comment 10

[Hanabishi]

Attachment: default.png

Comment 11

[Hanabishi]

Attachment: forcing.png

Comment 12

[Malus]

Attachment: All symbols with the `Segoe UI Symbol` font

The problem Gecko has here goes beyond the default emoji font, however:
The default emoji font in Gecko is in fact Segoe UI Emoji (as seen in the flag font.name-list.emoji in about:config), but somewhere in the rendering it messes with the fonts of the individual emojis: The incorrectly rendered black/white symbols (as described above) are rendered with the font Segoe UI Symbol, the correctly displayed emojis correctly have Segoe UI Emoji set as their font.
This can be seen with Firefox's font tab, as seen in the following images.
This means that the default emoji font does not play a role in this bug whatsoever, instead it is some rendering error of Gecko directly, in connection with an outdated emoji version as described above.

Comment 13

[Malus]

Attachment: All symbols with the `Segoe UI Emoji` font

Comment 14

[Chris Morgan]

I discovered something new about this just now: U+FE0E VARIATION SELECTOR-15 is being ignored when attached to an emoji that follows a coloured emoji. That places this as unequivocally a bug. (Before that discovery, it was fairly clearly a bug to me, but you could probably have argued it wasn’t actually wrong because of how loosely the algorithms are probably defined—though I’m not familiar with their details.)

To be clear, this is definitely not just something to do with font fallback ordering. There must be some actively buggy logic somewhere.

So,

• With spaces is fine: 👁 👄 👁
• Without spaces is inconsistent (and thus buggy): 👁👄👁
• With U+FE0E on each is fine: 👁︎👄︎👁︎
• With U+FE0F on each is fine: 👁️👄️👁️
• With U+FE0E on the EYEs only is definitely wrong: 👁︎👄👁︎

Comment 15

[Hanabishi]

(In reply to Chris Morgan from comment #14)
Here is what I see at latest dev FF79.

Comment 16

[Hanabishi]

Attachment: image.png

Comment 17

[Malus]

Firefox 82.0 has changed the situation: Now a broken (uncolored) emoji has no relation with a preceding intact (colored) emoji anymore.

Examples from this thread as comparison:

Comment 18

[Malus]

Attachment: from comment #14

Comment 19

[Malus]

Attachment: image.png

Comment 20

[Chris Morgan]

Confirmed also on Nightly (85), this bug is fixed: characters aren’t affecting subsequent characters, and the variation selectors are being respected.

Most would like it if it chose the coloured glyphs before the black-and-white glyphs, but that’s an enhancement rather than a bug, and definitely unrelated to this bug.

This bug should now be closed RESOLVED FIXED.

Comment 21

[Jonathan Kew [:jfkthame]]

Yes, this can be considered fixed -- primarily as a result of the patch in bug 1371386, I believe.

Regarding the original testcase from comment 0, it is expected that the "writing hand" and "eye" characters (when used without a variation selector) prefer the b/w rendering, because U+270D (understandably, as it's a longstanding symbol that dates back to Zapf Dingbats and the original LaserWriter era, I believe) and U+1F441 (more surprisingly, given that it is a modern addition) have the property Emoji_Presentation=No (by omission: see the second part of https://www.unicode.org/Public/UCD/latest/ucd/emoji/emoji-data.txt).

Comment 22

[Malus]

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

That is very interesting, I didn't know different characters have different properties controlling their presentation. Thanks for letting us know!