Closed Bug 1209480 Opened 4 years ago Closed 4 years ago
Canvas no longer able to render colour emojis (caused by switch to Skia)
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).
This broke emoji detection for WordPress, see https://core.trac.wordpress.org/ticket/34049 .
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.
While investigating, I discovered that loading BMP characters into Canvas appears to break existing rendered glyphs too. Attached GIF shows the behaviour.
George, do you think updating Skia would fix this?
It's very likely.
We don't have any data to support this, right?
Posted the site compatibility doc: https://www.fxsitecompat.com/en-US/docs/2015/canvas-fails-to-render-emojis-on-os-x/
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.
[Tracking Requested - why for this release]: Web content regression
Thanks Patrick, updated the doc.
Tracking as it is a (sad) regression.
(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.
Assignee: nobody → lsalzman
Assignee: lsalzman → nobody
This is coloured emojis only, right? I imagine something in the texture formats?
Summary: Canvas no longer able to render emojis (caused by switch to Skia) → Canvas no longer able to render colour emojis (caused by switch to Skia)
(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.)
(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.)
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.)
(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.
Depends on: 1082598
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.
This is fixed now, presumably by the skia update (bug 1082598).
Updated the site compatibility document accordingly.
4 years ago
Duplicate of this bug: 1237640
You need to log in before you can comment on or make changes to this bug.