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

Status: RESOLVED FIXED

(Core :: Graphics: Text, defect)

Description

[kvnmallari]

Attachment: Screen Shot 2013-10-02 at 4.39.53 PM.png

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.

Comment 1

[Liz Henry (:lizzard) (relman/hg->git project)]

Attachment: screenshot of emoji search

Comment 2

[Liz Henry (:lizzard) (relman/hg->git project)]

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.

Comment 3

[kvnmallari]

Nevermind the Google part, the emojis show properly on title bar but not on the page.

Comment 4

[kvnmallari]

Attachment: Screen Shot 2013-11-02 at 11.15.23 AM.png

Comment 5

[Jonathan Kew [:jfkthame]]

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?

Comment 6

[kvnmallari]

Attachment: 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

Comment 7

[Jonathan Kew [:jfkthame]]

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"?

Comment 8

[kvnmallari]

Attachment: 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.

Comment 9

[Jonathan Kew [:jfkthame]]

(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...

Comment 10

[Jonathan Kew [:jfkthame]]

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.

Comment 11

[kvnmallari]

So how do I force it to explicitly choose the font Apple Color Emoji? 
Sorry for the trouble.

Comment 12

[Jonathan Kew [:jfkthame]]

(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.)

Comment 13

[Jonathan Kew [:jfkthame]]

Could you try the experimental build from http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-ad27c9ba886c/try-macosx64/firefox-28.0a1.en-US.mac.dmg 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.

Comment 14

[kvnmallari]

Attachment: nightly.jpg

I tried what you said on Comment 5 using the Nightly version.

Comment 15

[Jonathan Kew [:jfkthame]]

Attachment: check for unexpected font substitution during Core Text shaping, and fall back to harfbuzz if this occurs

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 http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-49067e0fb60e/try-macosx64/firefox-35.0a1.en-US.mac.dmg and confirm whether this fixes the issue, that would be really helpful - thanks.

Comment 17

[Jonathan Kew [:jfkthame]]

Attachment: check for unexpected font substitution during Core Text shaping, and fall back to harfbuzz if this occurs

:smontagu confirmed that this patch fixes the garbage-rendering problem for him (see bug 989664).

Comment 18

[John Daggett (:jtd)]

What's the precise testcase to use here? Shouldn't we have that in a reftest, it that's possible?

Comment 19

[Jonathan Kew [:jfkthame]]

Try

   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.

Comment 20

[Jonathan Kew [:jfkthame]]

Review ping?

Comment 21

[Jonathan Kew [:jfkthame]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/371c154c2e9d

Comment 22

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/371c154c2e9d