Closed Bug 1440907 Opened 7 years ago Closed 7 years ago

Unicode "emoji" character not correctly displayed except if preceded by another one

Categories

(Core :: Graphics: Text, defect)

58 Branch
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 1239380

People

(Reporter: delgan.py, Unassigned)

Details

Attachments

(1 file)

Attached image unicode-firefox-bug.gif
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:58.0) Gecko/20100101 Firefox/58.0 Build ID: 20180206200532 Steps to reproduce: Hello. Looking at this two "emoji" unicode characters: * ✔️ (Heavy Check Mark, U+2714) * ❌ (Cross Mark, U+2746) This bug is quite weird: the rendering of these two characters depends on the order of them. For example, with "✔️❌", both characters are displayed correctly. But with "❌✔️", both are "weakly" rendered. If the cross mark is preceeded with the check mark, it is well displayed. But if it preceeded by a non-emoji character, it is not correctly displayed. Another weird behavhior: if I press "Enter" before the red cross mark, it does not modify the way it is displayed. If then I add a character at the start of the new line, the "weak" version is displayed, but if I remove the character, the good looking version does not come back. This happens on all input textarea, including the address bar of the browser. I made the test without any extension (I restarted Firefox in "safe mode"), the text encoding displayed in Firefox's options is "Unicode", I am using v58.0.2 (64 bits) on Windows 10. As this is hard to describe, and as I do not know if this depends on my Firefox installation, I made a gif to show the behavior: https://i.imgur.com/vhCyuON.gif Actual results: The check mark and cross mark rendering change according to the order of characters. Expected results: The check mark should be green and the cross mark should be red no matter which character preceeds each other.
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0 20180223220058 I can reproduce this in 58.0.2, but it works in the latest Nightly. I used mozregression-gui to verify it was fixed in Firefox 59 by bug 1032671. https://hg.mozilla.org/integration/autoland/json-pushes?changeset=f16b41dbddee25df808d00661d099a900e453e9e&full=1
Status: UNCONFIRMED → RESOLVED
Has Regression Range: --- → irrelevant
Has STR: --- → yes
Closed: 7 years ago
Component: Untriaged → Graphics: Text
Product: Firefox → Core
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: