My favorites | Sign in
Project Home Downloads Wiki Issues Code Search
New issue   Search
  Advanced search   Search tips   Subscriptions
Issue 62435: Emoji does not display in webpage contents on OS X Lion+
632 people starred this issue and may be notified of changes. Back to list
Reported by, Nov 8, 2010
Chrome Version       : 7.0.517.41
URLs (if applicable) :
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
     Safari 5: FAIL
  Firefox 3.x: OK
       IE 7/8: n/a

What steps will reproduce the problem?
1. Install Symbola font from (or any other font which includes the Emoji symbol for U+1F4A9)
2. View test page at

What is the expected result?
All four boxes should display the same pile of poo.

What happens instead?
On Kubuntu Linux 10.10 with stable Chrome release, the three Unicode character versions display correctly and are identical to the "Should look like" image.
On Mac OS X, the three Unicode character versions do not display; instead, I get the empty box character.

Please provide any additional information below. Attach a screenshot if

This is probably a much more general problem, but that's the Unicode character I noticed it with...
Oct 27, 2011
was: Unicode / font-fallback: Unicode pile of poo does not display on Mac OS X, works on Linux
Summary: Emoji does not display in webpage contents on OS X Lion
Labels: Hotlist-MacOSXLion
Oct 27, 2011
Thakis commented on  bug 90177 :

Happened to see this in WebKit/Tools/DumpRenderTree/mac/DumpRenderTree.cpp:

   [preferences setPictographFontFamily:@"Apple Color Emoji"];

Maybe related?
Nov 2, 2011
Although it's not a great idea to invent a new CSS generic family for emoji (imho), that's what's done. So, I believe by adding a new preference for PictorGraphFontFamily, we can fix this problem. I'll give it a shot as I mentioned in  bug 90177 . 

Nov 2, 2011
The webkit change for PictorGraphFontFamily is

The change will only work on Lion. We need to do some plumbing in Chrome and chrome's webkit.  

Jun 5, 2012
#22 katmomoi

The above page contains the full set of Emoji added to Unicode 6. The 2nd column uses the code points for some 720 Emoji characters.
On Mac OS Lion, there is Apple Color Emoji that can display all the Emoji on Safari. Unfortunately none of the Emoji displays on the latest Chrome.
Can we make sure that Chrome too displays all the characters on Mac using Mac OS Lion's built in font for Emoji? 
Jun 5, 2012
(+cc some WebKit fonts / i18n folks)
Jun 5, 2012
Probably needs

but that's not enough. (A html file that contains "😰" and has font-family: "Apple Color Emoji" doesn't show the character correctly either; once that works the rest should start working with the above CLs)
Jun 5, 2012
suggest that the emoji font is special; maybe the font serialization can't handle it?
Jun 5, 2012
To support Apple Color Emoji, we need to ask Skia people to use CTFontDrawGlyphs(), which available in 10.7 SDK. WebKit mac port uses the API.

Jun 6, 2012
I gave that a try, but failed to get it to work so far. Work in progress attached.
2.1 KB   View   Download
Jun 6, 2012
Stuff looks almost correct if I set the offset to {0,0}; I suppose coretext transformation order is slightly different.
Sep 18, 2012
 Issue 150599  has been merged into this issue.
Sep 19, 2012
 Issue 150748  has been merged into this issue.
Sep 21, 2012
In addition to the changes mentioned above, needs to be reverted too.
Sep 23, 2012
A few notes about SkFontHost_mac_coretext.cpp:

* SkFontHost::FilterRec needs to always use kLCD16_Format for bitmap fonts such as emoji, else it might create grayscale glyphs and emoji characters show up as greyscale. (attached patch has proof-of-concept code for this)

* On retina displays, bitmap fonts are currently rendered at half the resolution

* Gamma correction (or something) causes colors for bitmap fonts to be off. Skip doing this for bitmap fonts.

* Text is currently drawn white-on-black with a TODO to invert this. This is apparently needed for bitmap fonts, else they end up with inverted colors. (Or something further down in skia inverts, so a double-invert is needed to make that a noop). Also proof-of-concepted in the attached patch.
7.5 KB   View   Download
Sep 23, 2012
(No comment was entered for this change.)
Summary: Emoji does not display in webpage contents on OS X Lion+
Sep 23, 2012
(See  issue 151883  for the omnibox shift caused by emojis)
Sep 24, 2012
LayoutTests/fast/css/font-family-pictograph.html starts looking ok when forcing rec->fMaskFormat to kLCD32_Format (not kARGB32_Format surprinsingly) in SkFontHost::FilterRec(), and when sending SkScalerContext_Mac() down the leopard path always (which passes the true font size instead of 1 for the font size).

(Note: it's still pixel-scaled on retina.)
Oct 5, 2012
The following revision refers to this bug:

r160338 | | 2012-10-05T08:56:03.686369Z

Changed paths:

mac: Plumbing for the emoji font.

Since emoji is disabled in webkit for chromium, this has no observable effect yet.


Review URL:
Oct 5, 2012
After the above commit, the following changes are needed to get the proof-of-concept going:

1. Revert  in webkit (just 2 lines) locally
2. Apply the patch from comment 34

Issues with the patch:
* Emojis show up as lodpi on retina displays
* Baselines are messed up (bashi suggests this could be fixed by using the emoji font only for bitmap font glyphs)
* The skia patch is very messy

bashi says he'll try to get the skia part moving.
Oct 5, 2012
I added a couple of comments to (post-commit comment). They're just about font pref on Windows and Linux. 

Oct 15, 2012
The following revision refers to this bug:

r162045 | | 2012-10-16T02:11:47.859944Z

Changed paths:

Address review feedback for r160338

On Windows, use Segoe UI Symbol as emoji font.
On CrOS, use Droid Emoji.
Simplify the defaults, they're overridden anyway.


Review URL:
Nov 13, 2012
Emoji is shown correctly in Title (or when adding a bookmark).

Emoji is not correct when it's in the content.


Version 25.0.1323.1 dev
Feb 24, 2013
What needs to happen to get this to work? Note: The standard OSX Japanese IME inserts emoji 

type 'ichigo' you get not θ‹Ί only but also πŸ“ 
type 'bi-ru' and you get not only ビール but also 🍺 and 🍻
type 'ke-ki' and you get not only γ‚±γƒΌγ‚­but also 🍰 and πŸŽ‚

All this works in Safari on OSX and IE on Windows. Anything I can do to help it work on Chrome?
Feb 24, 2013
gman: See comment 41 and some of the previous comments. The most important thing is to figure out how to do the skia parts right (need to call the new CTFontDrawGlyphs() function and tell skia to use 32 bit glyphs; comment 41 has a somewhat-working patch).
Mar 8, 2013
I tried to put some πŸ’© into a code review but all I got was a box. I kind of think we should be able to use πŸ’© in code reviews, so this was pretty disappointing to me.

bashi, are you still working on the Skia side of this?
Apr 11, 2013
The same thing is happening in Chrome on Windows 8 (which has native support for emoji). Internet Explorer displays them correctly, but Chrome up till today doesn't...perhaps cause fkn Google doesn't support emoji in any of its OS, so it wants other OS users to see the web the same way its OS users do.
Apr 29, 2013
 Issue 236171  has been merged into this issue.
Jul 19, 2013
You can install this Chrome extension for emoji in the meantime:
Jul 20, 2013
What's required to resolve this issue and properly support emoji? Also, what's the status on Windows and ChromeOS? Emoji seem to be showing up properly for me on ChOS.
Jul 20, 2013
brian: See previous comments for what needs to be done. Summary:

1. Skia needs to be learn to draw 32bit rgba glyphs
2. Skia's mac text renderer needs to call CTFontDrawGlyphs() for bitmap fonts (see patch in comment 34)
(2b. Make sure they show up hidpi on retina displays)
3. Some minor plumbing needs to be done to enable this in skia (see comment 41)

CrOS uses vector fonts for Emoji and hence uses the regular font rendering paths for them. Apple decided that Emojis warrant introducing 32bit rgba bitmap fonts (which means they look bad at very large font sizes, but that's admittedly a rare use case), and skia doesn't support that new font mode yet.

I saw a design doc from reed@ about 32bit bitmap glyphs a while ago, I don't know what the status of that is.
Aug 16, 2013
 Issue 273491  has been merged into this issue.
Sep 27, 2013
JFYI : See bug 245397. Skia on Linux/Android can handle color glyphs with FreeType Android WebView support was added, which can be ported to Blink on Linux. 
Dec 18, 2013
(No comment was entered for this change.)
Jan 10, 2014
Win8.1/IE11 equivalent to this bug: Issue 333011
Jan 10, 2014
Please star the issue to indicate that you'd like to see it fixed, adding redundant comment only slows down the process.
Labels: Restrict-View-EditIssue
Jan 10, 2014
(No comment was entered for this change.)
Labels: -Restrict-View-EditIssue Restrict-AddIssueComment-EditIssue
Feb 9, 2014
Ran into this again today, came to check on things and see if I could help fix.  I see a plan laid out in comment 59, but that's almost 8 months ago and I know the font code has changed significantly since!  Curious if either Email or Ben have a status update as to what remains and if there are ways others can help with the remaining issues.  Thanks!
Feb 9, 2014
I'm slowly working on a fix, but it isn't very promising at the moment. I tried applying Nico's patch and cleaning up the Skia code, but his patch doesn't work anymore. :(
I spoke to Ben, and he mentioned he has looked a bit at it and had a sketch of patch, but he's been pretty busy with the Windows font stuff so I haven't got ahold of it yet. In any case, I was going to ask some Skia folks next week if they could point me in the right direction towards fixing this. 
Any and all comments welcome!
Mar 3, 2014
Here is the patch that I currently have, based on Nico's old patch. I'm building with the 10.7 sdk, so I temporarily took out the dlsym call to make sure that isn't what is breaking everything (it isn't). This code is currently drawing the glyphs with CTFontDrawGlyphs, which I understand is the right approach. 

The problem is that even though the baselines seem fine for the text, I've never been able to actually see an emoji glyph being drawn. The glyph bounds are fine (if I memset the background to green, I see the proper square where the emoji should be), and the loaded font has color glyphs, but they do not show up.
5.3 KB   Download
Mar 4, 2014
Mostly works for me. left to right: chrome, chromium with your patch, safari. (Colors are off, but hey.)

This is on 10.8, non-retina. Maybe it's not right on retina displays yet.

I did:

cd third_party/skia/src; patch -p1 < ~/Downloads/emoji.patch
cd -
cd third_party/WebKit
# change stuff
git diff
diff --git a/Source/platform/fonts/mac/ b/Source/platform/fonts/mac/
index a67362d..7cba3b3 100644
--- a/Source/platform/fonts/mac/
+++ b/Source/platform/fonts/mac/
@@ -119,8 +119,8 @@ PassRefPtr<SimpleFontData> FontCache::platformFallbackForCharacter(const FontDes
         return nullptr;
     // Chromium can't render AppleColorEmoji.
-    if ([[substituteFont familyName] isEqual:@"Apple Color Emoji"])
-        return nullptr;
+    //if ([[substituteFont familyName] isEqual:@"Apple Color Emoji"])
+        //return nullptr;
     // Use the family name from the AppKit-supplied substitute font, requesting the
     // traits, weight, and size we want. One way this does better than the original
Screen Shot 2014-03-04 at 11.40.02 AM.png
793 KB   View   Download
Mar 6, 2014
On 10.9, the patch doesn't work for me either, independent of retinaness.

(This is how Firefox added support:
Apr 8, 2014
(No comment was entered for this change.)
Apr 10, 2014
 Issue 361986  has been merged into this issue.
May 18, 2014
Here's a silly demo that shows that CTFontDrawGlyphs does the thing on 10.9, so the patch probably just has a few offsets off? Here's a screenshot of running this on 10.9, would be interesting to see if this has the same output on 10.8.
Screen Shot 2014-05-18 at 10.23.56 PM.png
100 KB   View   Download
1.1 KB   Download
Jun 6, 2014
FooView.m only shows a red rectangle on 10.8.
Jun 6, 2014
Given how consistently this patch works, I can't wait to try it out on 10.10 :(
Jun 12, 2014
The patch works on 10.10!
Aug 14, 2014
Great to hear that it works on 10.10. 
If it works on 10.10 (but not in earlier OS X), I think we should get this in potentially with a run-time OS version check to avoid a problem on earlier OS X (if any). 

I'm afraid we're getting a lot of bad PR on this issue. 
Aug 14, 2014
It will still be interesting to know how come it worked on 10.8 and 10.10 but not 10.9, and last time I checked the patch is still missing polishing from Skia side to fully work. Any chance to get more Skia developers to help understanding it better? I have tried but without more Skia background it's hard to understand how it is supposed to work.
Aug 14, 2014
I think rsesek@ was referring to Nico's red square patch. I dont think the emoji patch works on 10.10, or is in any shape ready to go out.

Aug 14, 2014
Right, I was testing Nico's FooView.m, which does not work on 10.8, but it does on 10.9 and 10.10. I definitely support just getting this done for modern OSes using a run-time check. We've been without emoji support for far too long.
Sep 2, 2014
I'll sync-up with bungeman tomorrow, and see if he has any insight.
Sep 2, 2014
(No comment was entered for this change.)
Sep 16, 2014
 Issue 414535  has been merged into this issue.
Sign in to add a comment

Powered by Google Project Hosting