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

RESOLVED FIXED in mozilla35

Status

()

RESOLVED FIXED
5 years ago
2 months ago

People

(Reporter: kvnmallari, Assigned: jfkthame)

Tracking

({fonts})

unspecified
mozilla35
All
Mac OS X
fonts
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(7 attachments, 1 obsolete attachment)

(Reporter)

Description

5 years ago
Created attachment 813013 [details]
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.
(Reporter)

Updated

5 years ago
Keywords: fonts
Created attachment 823622 [details]
screenshot of emoji search
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)
(Reporter)

Comment 3

5 years ago
Nevermind the Google part, the emojis show properly on title bar but not on the page.
Flags: needinfo?(kvnmallari)
(Reporter)

Comment 4

5 years ago
Created attachment 826244 [details]
Screen Shot 2013-11-02 at 11.15.23 AM.png
Component: Untriaged → Layout: Text
Product: Firefox → Core
(Assignee)

Comment 5

5 years ago
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?
(Reporter)

Comment 6

5 years ago
Created attachment 827176 [details]
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
(Assignee)

Comment 7

5 years ago
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"?
(Reporter)

Comment 8

5 years ago
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.
(Assignee)

Comment 9

5 years ago
(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...
(Assignee)

Comment 10

5 years ago
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.
(Reporter)

Comment 11

5 years ago
So how do I force it to explicitly choose the font Apple Color Emoji? 
Sorry for the trouble.
(Assignee)

Comment 12

5 years ago
(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.)
(Assignee)

Comment 13

5 years ago
Could you try the experimental build from http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/jkew@mozilla.com-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.
(Reporter)

Comment 14

5 years ago
Created attachment 830177 [details]
nightly.jpg

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

Comment 15

4 years ago
Created attachment 8485418 [details] [diff] [review]
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/jkew@mozilla.com-49067e0fb60e/try-macosx64/firefox-35.0a1.en-US.mac.dmg and confirm whether this fixes the issue, that would be really helpful - thanks.
(Assignee)

Updated

4 years ago
Flags: needinfo?(kvnmallari)
(Assignee)

Updated

4 years ago
Duplicate of this bug: 1063622
(Assignee)

Updated

4 years ago
Flags: needinfo?(mark)
(Assignee)

Updated

4 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Assignee)

Updated

4 years ago
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
(Assignee)

Comment 17

4 years ago
Created attachment 8486297 [details] [diff] [review]
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).
Attachment #8486297 - Flags: review?(jdaggett)
(Assignee)

Updated

4 years ago
Attachment #8485418 - Attachment is obsolete: true
(Assignee)

Updated

4 years ago
Assignee: nobody → jfkthame
Status: NEW → ASSIGNED
(Assignee)

Updated

4 years ago
Flags: needinfo?(mark)

Comment 18

4 years ago
What's the precise testcase to use here? Shouldn't we have that in a reftest, it that's possible?
(Assignee)

Comment 19

4 years ago
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.
(Assignee)

Comment 20

4 years ago
Review ping?

Updated

4 years ago
Attachment #8486297 - Flags: review?(jdaggett) → review+
(Assignee)

Comment 21

4 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/371c154c2e9d
Flags: needinfo?(kvnmallari)
Target Milestone: --- → mozilla35
https://hg.mozilla.org/mozilla-central/rev/371c154c2e9d
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED

Updated

4 years ago
Duplicate of this bug: 1090692
Depends on: 1089787
You need to log in before you can comment on or make changes to this bug.