EdgeHTML doesn't display color emoji well
Duplicate Issue #8476020 • See Issue #13583622
Details
Steps to reproduce
Send yourself an email to an Exchange account with the attached Emoji list as the body. Send in both text and HTML format. Do not override the font in HTML. You can send to an Outlook.com account if you have been migrated to the new Exchange/O365 based system but if you use your @microsoft.com email you will have Exchange OWA. Do not try the Hotmail backend or Gmail both of which play games with emoji which interferes with this.
You can see the behavior from the attached screenshots. Because this system limits the number of attachments, I had to drop Chrome 52 and Edge displaying the HTML message but you can try yourself.
I’ll describe the behavior.
With a text format message using Edge 14, the emoji are displayed with Segoe UI Symbol. Color is not used. Fitzpatrick modifiers are displayed separately. With Chrome 52, Segoe UI Emoji is used but in black and white, not color. The Fitzpatrick modifiers are separate. With Chrome 54, Segoe UI Emoji is used with color with Fitzpatrick modifiers integrated. This is what Edge should be doing.
With an HTML format message using Edge 14, most emoji are displayed in color with Segoe UI Emoji but many are missed. Chrome 52 matches the text body using Segoe OE Emoji in black and white. Chrome 54 matches the text body as well using Segoe UI Emoji in color.
Chrome on Android and iOS on Safari use color emoji in both cases.
Attachments
13 attachments
- Edge 14 - Text Format Message.PNG
- Chrome 54 - Text Format Message.PNG
- Chrome 52 - Text Format Message.PNG
- Chrome 54 - HTML Format Message.PNG
- Unicode 9.0 Emoji (Raw).txt
- 261d.html
- Outlook 2016 - Suits.png
- Outlook 2016 - 263A.png
- Edge 14 - HTML Format Message.PNG
- 261d.html
- Chrome 52 - HTML Format Message.PNG
- Outlook 2016 - Gender.png
- emoji.html
Comments and activity
-
Microsoft Edge Team
Brad E. Aug 12, 2016 2016-08-12T18:08:55.607Z
Changed Assigned To to “Brad E.”
OSG V. Aug 12, 2016 2016-08-12T18:33:17.243Z
Changed Assigned To to “Rick J.”
OSG V. Oct 6, 2016 2016-10-06T23:52:17.673Z
Changed Assigned To to “Christian F.”
Matt R. Oct 28, 2016 2016-10-28T01:34:34.293Z
Changed Assigned To from “Christian F.” to “Sergey M.”
Matt R. Oct 28, 2016 2016-10-28T15:39:30.967Z
Changed Status to “Confirmed”
Sergey M. Oct 28, 2016 2016-10-28T19:05:02.84Z
Changed Status from “Confirmed” to “Duplicate”
-
James M. Mar 31, 2017 2017-03-31T17:48:14.327Z Microsoft Edge Team
Hello,
Thank you for providing this information about the issue. We are pleased to report this feature is fixed in Edge 15063 and is available in our latest Insider Preview build.
Best Wishes,
The MS Edge Team -
Richard S. Mar 31, 2017 2017-03-31T18:25:46.693Z
Changed Status from “Duplicate”
-
Richard S. Mar 31, 2017 2017-03-31T18:25:49.1Z
It’s broken. I can’t tell which aspects are broken by Edge and which by Windows. I will try to attach a test file which displays correctly on 15063. One common issue is that many characters have both a text and emoji presentation. Depending on the character the default presentation may be emoji or text. Edge displays many characters using the wrong default. There is also an explicit text or emoji presentation modifier. These are often ignored and the wrong character displayed. The following is one such example. U+2916 should default to text. Edge inappropriately displays it as Emoji both by default and with an explicit text presentation override. See http://www.unicode.org/Public/emoji/5.0/ for details.
U+00002196
T
↖
↖︎
↖️My sample file, if I can attach it, may have bad examples with gender overrides. Please ignore this.
-
Richard S. Mar 31, 2017 2017-03-31T18:41:17.46Z
My sample file is attached as emoji,html, and again may have bad examples with gender overrides. Please ignore this aspect.
It appears that Edge almost always defaults to emoji presentation regardless of the default in the standard and always ignores the text and emoji presentation override modifiers.
In contrast, Safari on iOS 10.3 sometimes uses the wrong default presentation but does honor the presentation overrides. It appears to ignore the text presentation override in some cases which I suspect are when it doesn’t have a non-emoji glyph but I can’t be sure.
Chrome 57 on Android 7.1.1 is better than Safari. It also gets the default presentation wrong in some cases but very few in comparison to Safari. It also does honor the presentation override modifier except in cases which I suspect are also when a non-emoji presentation glyph is not available.
-
Microsoft Edge Team
Steven K. Mar 31, 2017 2017-03-31T20:43:43.837Z
Changed Assigned To to “James M.”
James M. Mar 31, 2017 2017-03-31T21:13:39.03Z
Changed Status to “Fixed”
-
James M. Mar 31, 2017 2017-03-31T21:13:39.03Z Microsoft Edge Team
Hello,
Thank you for assisting us with this case and being part of the solution. If you have discovered new problems, whether a direct result of the fix or not, please open a new case so we can easily track the progress. We look forward to additional feedback you have on how we can improve Microsoft Edge.
Best Wishes,
The MS Edge Team -
Richard S. Apr 1, 2017 2017-04-01T01:14:55.733Z
Changed Status from “Fixed”
-
Richard S. Apr 1, 2017 2017-04-01T01:14:55.92Z
Not a new bug. This one was fixed incorrectly. Do you still need a new issue to deal with this fix being incorrect?
-
Microsoft Edge Team
James M. Apr 3, 2017 2017-04-03T14:58:07.62Z
Changed Assigned To to “James M.”
OSG V. Apr 4, 2017 2017-04-04T17:52:45.337Z
Changed Assigned To to “Christian F.”
Matt R. Apr 20, 2017 2017-04-20T21:38:56.72Z
Changed Assigned To from “Christian F.” to “Matt R.”
Sergey M. Jun 7, 2017 2017-06-07T01:48:31.103Z
Changed Assigned To from “Matt R.” to “Sergey M.”
Matt R. Jun 9, 2017 2017-06-09T22:18:48.377Z
Changed Status to “Confirmed”
-
Richard S. Jun 9, 2017 2017-06-09T22:31:11.527Z
Please test with the data at http://www.unicode.org/Public/emoji/5.0/. In particular, make sure that every emoji is tested as is, with a U+FE0E text presentation selector, and with a U+FE0F emoji presentation selector. The Unicode data will also identify which emoji support gender modifiers and skin tone modifiers which Edge and/or the Win10 Creators Update also got wrong in some cases.
-
Microsoft Edge Team
Frank O. Jun 14, 2017 2017-06-14T17:54:46.277Z
Changed Steps to Reproduce
Sergey M. Jul 12, 2017 2017-07-12T16:40:10.527Z
Changed Status from “Confirmed” to “Fixed”
-
Sergey M. Jul 12, 2017 2017-07-12T16:41:09.08Z Microsoft Edge Team
Unfortunately, I can’t implement full emoji presentation classification in this release. We only picked few characters that were critical for UI cases and hardcoded them to be presented as text. Everything else will be rendered as colored emoji.
But I have implemented support for presentation selcetors, so page author can explicitly choose presentation form.
-
Richard S. Jul 12, 2017 2017-07-12T16:54:54.297Z
Which build has this fix?
Does Edge in RS3 support the full set of gender and skin tone modifiers?
-
Sergey M. Jul 13, 2017 2017-07-13T16:38:35.2Z Microsoft Edge Team
Build with a fix is not public yet. I can’t tell exactly when, but it should be out soon.
Does Edge in RS3 support the full set of gender and skin tone modifiers?
Yes, as far as I am aware. Last fix went in very recently, it is not public yet as well.
-
Microsoft Edge Team
pbstools Jul 22, 2017 2017-07-22T06:05:48.07Z
Changed Status from “Fixed” to “Fixed, not yet flighted”
-
Richard S. Aug 3, 2017 2017-08-03T05:13:09.53Z
Changed Status from “Fixed, not yet flighted”
-
Richard S. Aug 3, 2017 2017-08-03T05:13:09.953Z
It looks like 16257.1 has a fix for this but there are still issues. Variants of U+261D show this. The crux is that a presentation selector together with a gender selector looks to cause both to be mishandled. I’ll attach a file if reopening this enables it.
-
Richard S. Aug 3, 2017 2017-08-03T05:14:07.567Z
I’ve attached 261d.html.
-
Sergey M. Aug 3, 2017 2017-08-03T17:59:41.123Z Microsoft Edge Team
Can you explain what looks wrong to you with U+261D?
I see gender modifier turned monochrome when followed by emoji presentation selector. This is issue with Segoe UI Emoji font. On Edge side everything behaves as it should, it passes all characters to the font. I would suggest you open separate issue for Segoe UI Emoji incorrectly rendering gender modifiers.
Is there anything else that I missed?
Thanks, Sergey -
Richard S. Aug 3, 2017 2017-08-03T22:37:49.517Z
My first 261d.html was bad. I uploaded a second which has the URL https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/attachment/8476020/7540773/. The mistake in the first is that it had the text/emoji presentation selector twice. The order of characters should be emoji base then optional skin tone selector then gender ZWJ sequence then presentation selector. This is the order seen in http://www.unicode.org/Public/emoji/5.0/emoji-zwj-sequences.txt (e.g. 1F46E 1F3FB 200D 2640 FE0F).
261D demonstrates the issue that the text presentation is not honored when a gender is also specified. It is the case that even for characters with a default text presentation, the use of a skin token or gender is supposed to change the default presentation to emoji, I don’t see anywhere in the spec that an explicit text presentation should be ignored.
The character U+1F46F, which I also included in the attached HTML, demonstrates not only this but a regression from the previous insider build. When both gender and skin tone are present, neither are combined with the base character. This is a regression from both the previous insider build as well as 15063 which combined the skin tone selector but did not support the gender selector.
I do also see the issue of the gender selector being displayed in text form. I would report it but it’s unclear if you want this reported as an Edge issue. If so, I will. If you mean to report it against Windows, I don’t have a way except for the feedback hub which is pretty useless for a bug that will likely have a count of one.
-
Microsoft Edge Team
Steven K. Aug 4, 2017 2017-08-04T05:03:06.843Z
Changed Assigned To to “Sergey M.”
-
Sergey M. Aug 4, 2017 2017-08-04T17:25:53.26Z Microsoft Edge Team
You are right that presentation selector can follow emoji sequence, I’ll take care of that. Issue with U+1F46F actually has same root cause in the font as U+261D and they are both already fixed.
And you can always report this kind of issues in Edge database. If actual problem is in Windows, your bug will be appropriately re-routed.
-
Richard S. Aug 4, 2017 2017-08-04T17:37:21.723Z
I think the text and emoji presentation selectors must always be last. My reading of the BNF fragments in http://www.unicode.org/reports/tr51/ is that this is the case. Also, from this document, the following statement suggests the same.
“A text presentation selector breaks an emoji zwj sequence, preventing characters on either side from displaying as a single image. The two partial sequences should be displayed as separate images, each with presentation style as specified by any presentation selectors present, or by default style for those emoji that do not have any variation selectors.”
-
Microsoft Edge Team
Sergey M. Aug 16, 2017 2017-08-16T17:19:21.21Z
Changed Status to “Fixed, not yet flighted”
-
Richard S. Sep 23, 2017 2017-09-23T04:24:58.92Z
Changed Status from “Fixed, not yet flighted”
-
Richard S. Sep 23, 2017 2017-09-23T04:24:59.31Z
In 16296, all of http://unicode.org/Public/emoji/5.0/emoji-zwj-sequences.txt looks OK.
The test at http://unicode.org/Public/emoji/5.0/emoji-test.txt is the best it has been but still has issues.
The following should use emoji presentation. Both the default and explicit emoji presentation are using text presentation. These display correctly with emoji presentation in an email message body in Outlook 2016 running on Win 10 RS3 16296. See attached pictures "Outlook 2016 - 263A.png", "Outlook 2016 - Suits.png", and “Outlook 2016 - Gender.png”
263A FE0F ; fully-qualified # ☺️ smiling face
263A ; non-fully-qualified # ☺ smiling face2660 FE0F ; fully-qualified # ♠️ spade suit
2660 ; non-fully-qualified # ♠ spade suit
2665 FE0F ; fully-qualified # ♥️ heart suit
2665 ; non-fully-qualified # ♥ heart suit
2666 FE0F ; fully-qualified # ♦️ diamond suit
2666 ; non-fully-qualified # ♦ diamond suit
2663 FE0F ; fully-qualified # ♣️ club suit
2663 ; non-fully-qualified # ♣ club suit2640 FE0F ; fully-qualified # ♀️ female sign
2640 ; non-fully-qualified # ♀ female sign
2642 FE0F ; fully-qualified # ♂️ male sign
2642 ; non-fully-qualified # ♂ male signThe following are also bad with explicit emoji presentation yet still rendered as text
00A9 FE0F ; fully-qualified # ©️ copyright
00AE FE0F ; fully-qualified # ®️ registered
2122 FE0F ; fully-qualified # ™️ trade markThese are all bad except for last, keycap 10. This may be an issue with Segoe UI Emoji.
subgroup: keycap
0023 FE0F 20E3 ; fully-qualified # #️⃣ keycap: #
0023 20E3 ; non-fully-qualified # #⃣ keycap: #
002A FE0F 20E3 ; fully-qualified # *️⃣ keycap: *
002A 20E3 ; non-fully-qualified # *⃣ keycap: *
0030 FE0F 20E3 ; fully-qualified # 0️⃣ keycap: 0
0030 20E3 ; non-fully-qualified # 0⃣ keycap: 0
0031 FE0F 20E3 ; fully-qualified # 1️⃣ keycap: 1
0031 20E3 ; non-fully-qualified # 1⃣ keycap: 1
0032 FE0F 20E3 ; fully-qualified # 2️⃣ keycap: 2
0032 20E3 ; non-fully-qualified # 2⃣ keycap: 2
0033 FE0F 20E3 ; fully-qualified # 3️⃣ keycap: 3
0033 20E3 ; non-fully-qualified # 3⃣ keycap: 3
0034 FE0F 20E3 ; fully-qualified # 4️⃣ keycap: 4
0034 20E3 ; non-fully-qualified # 4⃣ keycap: 4
0035 FE0F 20E3 ; fully-qualified # 5️⃣ keycap: 5
0035 20E3 ; non-fully-qualified # 5⃣ keycap: 5
0036 FE0F 20E3 ; fully-qualified # 6️⃣ keycap: 6
0036 20E3 ; non-fully-qualified # 6⃣ keycap: 6
0037 FE0F 20E3 ; fully-qualified # 7️⃣ keycap: 7
0037 20E3 ; non-fully-qualified # 7⃣ keycap: 7
0038 FE0F 20E3 ; fully-qualified # 8️⃣ keycap: 8
0038 20E3 ; non-fully-qualified # 8⃣ keycap: 8
0039 FE0F 20E3 ; fully-qualified # 9️⃣ keycap: 9
0039 20E3 ; non-fully-qualified # 9⃣ keycap: 9
1F51F ; fully-qualified # 🔟 keycap 10 -
Richard S. Sep 23, 2017 2017-09-23T04:31:23.753Z
The non-fully qualified variants below look to default to text presentation so these may be broken in Outlook. The fully qualified variants with an emoji presentation selector obviously have emoji presentation. I am not sure what the rule is for the non-fully qualified keycap sequences which look OK here but look like crap in the TXT file.
263A ; non-fully-qualified # ☺ smiling face
2660 ; non-fully-qualified # ♠ spade suit
2665 ; non-fully-qualified # ♥ heart suit
2666 ; non-fully-qualified # ♦ diamond suit
2663 ; non-fully-qualified # ♣ club suit
2640 ; non-fully-qualified # ♀ female sign
2642 ; non-fully-qualified # ♂ male sign -
Richard S. Sep 24, 2017 2017-09-24T23:19:24.887Z
The keycap problems are an Edge issue. Chrome 61 on RS3 16296 displays the fully qualified variants correctly. The non-fully qualified keycaps are as bad as they are in Edge and that may be a font issue.
-
Microsoft Edge Team
James M. Sep 26, 2017 2017-09-26T22:43:40.12Z
Changed Assigned To to “James M.”
OSG V. Oct 2, 2017 2017-10-02T23:45:03.587Z
Changed Assigned To to “wptcomptri@microsoft.com”
Matt R. Nov 1, 2017 2017-11-01T18:32:59.317Z
Changed Status to “Duplicate”
-
Matt R. Nov 1, 2017 2017-11-01T18:32:59.317Z Microsoft Edge Team
Thanks Richard, I believe the remaining issues you describe are now covered by bug 13583622, so resolving this bug as duplicate of 13583622.
-
Anonymous Nov 1, 2017 2017-11-01T18:37:08.797Z Microsoft Edge Team
This bug has marked as duplicate. Please follow the parent issue to get new updates.
You need to sign in to your Microsoft account to add a comment.
Sign in