Closed Bug 923007 Opened 10 years ago Closed 9 years ago

presence of emoji-style variation selector breaks rendering of some symbols on OS X [was: Heart emoji won't show]


(Core :: Graphics: Text, defect)

Not set





(Reporter: kvnmallari, Assigned: jfkthame)



(Keywords: fonts)


(7 files, 1 obsolete file)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Firefox/24.0 (Beta/Release)
Build ID: 20130910160258

Steps to reproduce:

Saw an unusual character:(❤️❤️ ) on Instagram, tried to google it.

Actual results:

No results but the header showed the character was two hearts.

Expected results:

The characters should've been hearts at first.
Keywords: fonts
Do you mean that when you pasted the three characters you typed in parenthesis into a search engine, you expect that the character would have showed up either in the text input box for that search engine? Or in the results of the search?  

I'm pasting in the three character sequence ❤️❤️   and then the emoji for two hearts ❤❤   When I search for the sequence using Google in Firefox 24 on a Mac I get an autocomplete with the heart emoji, but the search results are blank as in your attachment.  Searching in Chrome and Safari returns the same negative results, so I'm not sure this is a Firefox bug.
Flags: needinfo?(kvnmallari)
Nevermind the Google part, the emojis show properly on title bar but not on the page.
Flags: needinfo?(kvnmallari)
Component: Untriaged → Layout: Text
Product: Firefox → Core
What version of OS X are you running?

Do the hearts show correctly here in comment #0 and comment #2 of this bug report?

Please try the following: copy and paste the text

   data:text/html;charset=utf-8,a &%23x2764;&%23xFE0F; b

into the URL bar of a new tab. Does the heart icon show on the page, or only the "a  b" letters?

Then open the Inspector panel (menu: Tools > Web Developer > Inspector, or Cmd-Opt-C), and click the Fonts tab in the right-hand pane. What font(s) does it list as being used?
Attached image Untitled.jpg
I'm using OS X Mavericks. I did a clean install.
Firefox 25. Add-ons are: AdBlock Plus, DownThemAll, Greasemonkey & Twitter Address Bar Search.
Only changed ui.SpellCheckerUnderlineStyle in about:config
Ah, I suspect this may be related to Mavericks. I'm on 10.7, which is probably why I can't reproduce the problem.

How about the simplified example:

  data:text/html;charset=utf-8,a &%23x2764; b

Does this display a heart, or still "junk"?
Attached image works.jpg
It worked.
Not sure if it's a Mavericks problem though, since I posted this problem when I was still using Mountain Lion.
(In reply to kvnmallari from comment #8)
> Created attachment 827237 [details]
> works.jpg
> It worked.
> Not sure if it's a Mavericks problem though, since I posted this problem
> when I was still using Mountain Lion.

OK, thanks. So it's the presence of the U+FE0F variation selector after the base character code that is somehow triggering the problem on OS X 10.9 (and 10.8, it seems), but not on 10.7.

My guess is that Apple has implemented some special "magic" behavior in Core Text (happening somewhere under our call to CTLineCreateWithAttributedString). I think it recognizes the presence of the U+FE0F selector and internally switches to the Color Emoji font, even though our font-matching process has chosen Menlo and specified this in the attributed string. Thus Core Text shaping gives us back glyph IDs that come from the Color Emoji font, but we aren't aware of the switch that CT has done, so we still try to draw them using Menlo - and get junk.

John, do you have a 10.8/10.9 system on hand where you could confirm this? I haven't upgraded yet...
By the way, kvnmallari: this means that (if I'm understanding it correctly) most emoji will show correctly (in color) for you; the problem only arises with examples like the heart that have been "unified" with pre-existing Unicode symbols, and hence are supported in other fonts besides the Apple Color Emoji font - such as Menlo, Symbol, Dingbats, etc. In this case, the font fallback process in Firefox may pick such a font (unless the Color Emoji font is explicitly chosen in CSS), and then Core Text steps in and confuses things.

If you add an explicit font-family setting to the example:

  data:text/html,<p style="font-family:apple color emoji">a &%23x2764;&%23xFE0F; b

then I suspect it will display fine. But of course this doesn't help with occurrences on random web pages in the wild.
So how do I force it to explicitly choose the font Apple Color Emoji? 
Sorry for the trouble.
(In reply to kvnmallari from comment #11)
> So how do I force it to explicitly choose the font Apple Color Emoji? 

For general web pages, I don't think there's any practical way for you to work around it; we'll need to adapt the Gecko code in some way to handle this case.

The example in comment 10 should demonstrate that -if- the color emoji font is specified, it'll display properly (does it?), but when emoji characters are inserted in general content, there's no way for you to override their styling.

(Actually, that's probably not strictly true: I presume something like a Greasemonkey script could be created to try and work around this by finding the relevant character sequences and applying the color emoji font to them. But that's not something I really know much about.)
Could you try the experimental build from and let me know whether the heart in the various testcases here renders properly with it? If so, this may point towards a solution.

This build is using a version of the patch from bug 543200, which I think may help here. The patch involved still needs some further attention before it's ready to land, but if it fixes this bug, that may give us the added impetus to bring it to completion.
Attached image nightly.jpg
I tried what you said on Comment 5 using the Nightly version.
I've put together an experimental patch that aims to work around the problem here; if people who can reproduce the bug (i.e. running OS X 10.8 or 10.9, as I understand it) could try the build from and confirm whether this fixes the issue, that would be really helpful - thanks.
Flags: needinfo?(kvnmallari)
Flags: needinfo?(mark)
Ever confirmed: true
Component: Layout: Text → Graphics: Text
Hardware: x86 → All
Summary: Heart emoji won't show. → presence of emoji-style variation selector breaks rendering of some symbols on OS X [was: Heart emoji won't show]
Version: 24 Branch → unspecified
:smontagu confirmed that this patch fixes the garbage-rendering problem for him (see bug 989664).
Attachment #8486297 - Flags: review?(jdaggett)
Attachment #8485418 - Attachment is obsolete: true
Assignee: nobody → jfkthame
Flags: needinfo?(mark)
What's the precise testcase to use here? Shouldn't we have that in a reftest, it that's possible?

   data:text/html;charset=utf-8,a &%23x2764;&%23xFE0F; b

(from comment 5), for example. If you're on 10.8 or 10.9, I believe this will misrender without the patch here.

I suppose we could have a reftest that compares this to the rendering without the variation selector, but that will fail as soon as we actually implement bug 727276, or possibly bug 543200.
Review ping?
Attachment #8486297 - Flags: review?(jdaggett) → review+
Flags: needinfo?(kvnmallari)
Target Milestone: --- → mozilla35
Closed: 9 years ago
Resolution: --- → FIXED
Depends on: 1089787
You need to log in before you can comment on or make changes to this bug.