1239380 - Emoji in input fields appear in black/white or Color depending on their order ✨

Status: RESOLVED FIXED

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

Description

[Markus Jaritz [:designakt] (UX)]

Attachment: emojiBWColor.gif

✨

Comment 1

[Markus Jaritz [:designakt] (UX)]

This row of emoji appears in as 3 emoji in black and white, and 3 emoji in color. Whether they appear in b/w or color is determined by the order of the emoji.
I saw those in input fields in Firefox and Thunderbird, Gijs mentioned that Chatzilla on Win 8.1 shows the same behavior. Other browsers (Edge, Chrome) show all icons in black and white, or color, but do not mix within one input field.

I would expect that all emoji are in color all the time, and that this does not depend on the order.

(Experienced on Nightly 46.0a1 (2016-01-12) on Windows 10)

(and apparently Bugzilla will ignore everything after one emoji, which is the reason that the description is only the first emoji of the sequence I wanted to post.)
Here is a link to the sequence I am talking about, but can't poste here:
https://twitter.com/designakt/status/687312386093625344

Comment 2

[Justin Dolske [:Dolske]]

Attachment: Testcase

Comment 3

[Justin Dolske [:Dolske]]

Attachment: Testcase

(Let's try this again, last attempt seems to have character encoding issues)

Comment 4

[Justin Dolske [:Dolske]]

Attachment: Testcase

Oh, come _on_. Trying again, last attachment worked from a web server!

Comment 5

[Justin Dolske [:Dolske]]

Finally. Attachment 8707561 [details] shows the black glyphs on the first line, and colored emoji on the second with Firefox on Windows 10. Edge, IE, and Chrome show black glyphs for both lines.

Comment 6

[Jonathan Kew [:jfkthame]]

(In reply to Markus Jaritz [:maritz] (UX) from comment #1)
> (and apparently Bugzilla will ignore everything after one emoji, which is
> the reason that the description is only the first emoji of the sequence I
> wanted to post.)

Actually, the problem here is that bugzilla won't accept characters beyond Plane 0 of Unicode, and just truncates the text if they are present. The "sparkles" symbol that came first in the example is U+2728, so that was fine, but the next symbols were from the U+1Fxxx emoji block, and bugzilla can't cope with them.

(In reply to Justin Dolske [:Dolske] from comment #5)
> Finally. Attachment 8707561 [details] shows the black glyphs on the first
> line, and colored emoji on the second with Firefox on Windows 10. Edge, IE,
> and Chrome show black glyphs for both lines.

Part of what's happening here is that when font fallback is happening (as is generally the case for emoji dropped into regular text, without explicitly specifying an emoji font), gfxFontGroup::FindFontForChar will try to keep using the same font for a run of characters, to reduce "ransom-note" effects where each character individually falls back to a different font.

Whether you get the Segoe UI Symbol font (B/W) or Segoe UI Emoji (color) for the entire sequence, then, is determined by which font we pick for the first of the characters. Which suggests we're finding the B/W symbol font rather than the (desired) color emoji one for U+2728.

I suspect bug 1032671 may help here; cc'ing m_kato.

Comment 7

[MDN Team (:mdn-dev)]

Commits pushed to master at https://github.com/mozilla/kuma

https://github.com/mozilla/kuma/commit/5d21d34d10b8a3469e579da3a7b239eb4ce1b762
Fix bug 1239380: Switch to py.test

This is the bare minimum amount of work required to switch from
nose/django-nose to py.test/pytest-django.

Several things to know:

1. I changed the SkipTest things to xfail since that's closer to what
   they are (i.e. "This thing fails and we don't know why--look at it
   later")

2. I removed the attr() things because they seemed arbitrary,
   inconsistent and not documented anywhere I could find. I'll make sure
   to note this in the email I send after this lands.

3. I reimplemented eq_ and ok_ rather than go through and change these
   to their py.test equivalents. We can change them over as a code
   cleanup step done on a future rainy day.

https://github.com/mozilla/kuma/commit/8a4a2173fe587d716148a74d5b11c7ca83a7ca6f
Fix bug 1239380: Remove vestiges of NOSE in settings

https://github.com/mozilla/kuma/commit/a8a8bebb8227fdc9bad5302e61d949ee7eeee811
Fix bug 1239380: Update testing documentation

https://github.com/mozilla/kuma/commit/3f500686a71499ded991f0732737e8a3c0f59d9d
Fix bug 1239380: Update Makefile

https://github.com/mozilla/kuma/commit/d9e126ac6580f6f7f096994f0cfc9555067f85ab
Fix bug 1239380: Remove --reuse-db

https://github.com/mozilla/kuma/commit/f21c524820b870126217c26a344eb37bd6ba78ec
Fix bug 1239380: Re-add marks

https://github.com/mozilla/kuma/commit/4b3c0d75162318224bbb032fd0ceecc1b51f4f33
Fix bug 1239380: Add .cache to .gitignore

https://github.com/mozilla/kuma/commit/605767f1468370aa050a877f05855c633ad2384a
Fix bug 1239380: Remove nose usage from test_commands

https://github.com/mozilla/kuma/commit/dc01f40f20e43bc6c46bb3ff8cf2c51b31850912
Fix bug 1239380: Fix flake8 errors

https://github.com/mozilla/kuma/commit/460f0ec528d102d88127930617652de1784b6ac6
Merge pull request #3757 from mozilla/1239380-pytest

Fix bug 1239380: Switch to py.test

Comment 8

[Will Kahn-Greene [:willkg] ET needinfo? me]

Sorry--total screw up on my part. Reopening.

Comment 9

[Makoto Kato [:m_kato]]

I have landed bug 1032671, so I think that is fixed (I cannot reproduce the latest Nightly).  Could you still reproduce this?

Comment 10

[Markus Jaritz [:designakt] (UX)]

(In reply to Makoto Kato [:m_kato] (slow due to PTO?) from comment #9)
> I have landed bug 1032671, so I think that is fixed (I cannot reproduce the
> latest Nightly).  Could you still reproduce this?

Looks fixed to me. Can not reproduce in Nightly anymore. Thanks!