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)
Tracking
()
RESOLVED
DUPLICATE
of bug 1239380
People
(Reporter: delgan.py, Unassigned)
Details
Attachments
(1 file)
8.81 KB,
image/gif
|
Details |
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.
Comment 1•7 years ago
|
||
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.
Description
•