1209480 - Canvas no longer able to render colour emojis (caused by switch to Skia)

Status: RESOLVED FIXED

(Core :: Graphics: Canvas2D, defect)

Description

[Markus Stange [:mstange]]

This is a regression in Firefox 41 caused by the switch to Skia canvas (bug 932958).

STR:
 1. Load attachment 8667228 [details] .
 2. Observe missing smiley face in the first line of text (which is a canvas).

Comment 1

[Markus Stange [:mstange]]

This broke emoji detection for WordPress, see https://core.trac.wordpress.org/ticket/34049 .

Comment 2

[Ryan McCue]

In case it's relevant (although I suspect it's using a different renderer): rendering an SVG which contains a foreignObject with emoji in HTML *does* work.

Comment 3

[Ryan McCue]

Attachment: ff41-rendering-bug.gif

While investigating, I discovered that loading BMP characters into Canvas appears to break existing rendered glyphs too. Attached GIF shows the behaviour.

Comment 4

[Markus Stange [:mstange]]

George, do you think updating Skia would fix this?

Comment 5

[George Wright (:gw280) (needinfo me!)]

It's very likely.

Comment 6

[Milan Sreckovic [:milan] (needinfo for best results)]

We don't have any data to support this, right?

Comment 7

[Kohei Yoshino [:kohei]]

Posted the site compatibility doc: https://www.fxsitecompat.com/en-US/docs/2015/canvas-fails-to-render-emojis-on-os-x/

Comment 8

[patrickkettner]

For what its worth, Wordpress is using Modernizr for its emoji detection, so this actually broke the emoji detection for anything using Modernizr's detect.

Comment 9

[Jeff Muizelaar [:jrmuizel]]

[Tracking Requested - why for this release]: Web content regression

Comment 10

[Kohei Yoshino [:kohei]]

Thanks Patrick, updated the doc.

Comment 11

[Sylvestre Ledru [:Sylvestre]]

Tracking as it is a (sad) regression.

Comment 12

[Milan Sreckovic [:milan] (needinfo for best results)]

(In reply to Sylvestre Ledru [:sylvestre] from comment #11)
> Tracking as it is a (sad) regression.

I get to use my one non-technical comment on the bug.  Well played with the wording.  "Sad" regression with non-working emojis.  A winning pun.

Comment 13

[Milan Sreckovic [:milan] (needinfo for best results)]

This is coloured emojis only, right?  I imagine something in the texture formats?

Comment 14

[Ryan McCue]

(In reply to Milan Sreckovic [:milan] from comment #13)
> This is coloured emojis only, right?  I imagine something in the texture
> formats?

Seems like it's only coloured emoji, yeah. Of the emoji on the BMP, U+2705 White Heavy Check Mark does not render correctly, but U+2714 Heavy Check Mark does.

As noted in comment #3, other non-emoji characters (such as mathematical script capitals) appear to break too, but cause other bugs.

(I meant non-BMP characters in that comment, not BMP.)

Comment 15

[Ryan McCue]

(In reply to patrickkettner from comment #8)
> For what its worth, Wordpress is using Modernizr for its emoji detection, so
> this actually broke the emoji detection for anything using Modernizr's
> detect.

We actually have our own script for detecting emoji support: https://core.trac.wordpress.org/browser/trunk/src/wp-includes/js/wp-emoji-loader.js

I just checked though, and it appears Modernizr uses a similar test, and is also affected: https://github.com/Modernizr/Modernizr/blob/master/feature-detects/emoji.js

(Modernizr doesn't include a test for bold text with emoji, which breaks in Chrome (presumably also using Skia), nor does it include a test for flag emoji.)

Comment 16

[Milan Sreckovic [:milan] (needinfo for best results)]

Both Skia (doesn't work) and Cairo (works) use NativeFontType::MAC_FONT_FACE.  On Windows, with the GDI font back end, under Skia or Cairo, we get the outline, but not the fill, which I imagine is expected.  As far as Skia goes, I see us getting into the code where the best we can expect is an outline (single color.)

Comment 17

[Milan Sreckovic [:milan] (needinfo for best results)]

(In reply to Markus Stange [:mstange] from comment #4)
> George, do you think updating Skia would fix this?

(In reply to George Wright (:gw280) (:gwright) from comment #5)
> It's very likely.

It does appear some work was done in Skia late 2014 and early 2015 to support colored glyphs.  The full Skia update is going to take a while, but we may be able to cherry pick this out.

Comment 18

[Milan Sreckovic [:milan] (needinfo for best results)]

I can see us getting the Skia update in 46, perhaps as early as 45, but it's difficult to say how complicated it will get.  Don't see us getting a solution to this problem beforehand.

Comment 19

[Markus Stange [:mstange]]

This is fixed now, presumably by the skia update (bug 1082598).

Comment 20

[Kohei Yoshino [:kohei]]

Updated the site compatibility document accordingly.