Summary: Emoji in input fields appear in black/white or Color depending on their order ✨ → Emoji in input fields appear in black/white or Color depending on their order ✨
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
Attachment #8707554 - Attachment mime type: text/plain → text/html
Created attachment 8707561 [details] Testcase Oh, come _on_. Trying again, last attachment worked from a web server!
Attachment #8707559 - Attachment is obsolete: true
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.
(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.
Depends on: 1032671
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
Sorry--total screw up on my part. Reopening.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
11 months ago
Priority: -- → P3
I have landed bug 1032671, so I think that is fixed (I cannot reproduce the latest Nightly). Could you still reproduce this?
(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!
Status: REOPENED → RESOLVED
Last Resolved: 2 years ago → 7 months ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.