Emoji detection is broken on FF41, OS X 10.10

[rmccue]

Discussed this one with @pento, and it looks like the emoji detection is broken in Firefox right now. The detection gives me white images (albeit with noise) for both the flag and normal emoji detection.

(I happen to have the built-in tracker blocking turned on, but that shouldn't affect generation of the detection images, so I don't suspect it's relevant.)

Investigating further.

[rmccue]

The following doesn't render emoji on Firefox (or Chrome; works in Safari): ​http://codepen.io/anon/pen/YypeNm

Despite this, emoji in HTML works fine for me, including flag emoji.

[rmccue]

So, as it turns out, FF doesn't render emoji on Canvas, just in HTML. Thankfully, it turns out we can use SVG's foreignObject to load HTML into SVG, then SVG into Canvas, and check that instead.

​http://codepen.io/anon/pen/zvoWOQ demonstrates the technique, and is consistent with support across FF, Chrome and Safari. (Safari needs the blob type to be image/svg and doesn't work with the suggested image/svg;charset=utf-8 from MDN)

[rmccue]

Updated the pen to remove createObjectURL in favour of data URIs, which should retain IE9 support.

Edit: As it turns out, this taints the canvas due to ​https://bugs.webkit.org/show_bug.cgi?id=129172 :(

Edit 2: Chrome ​treats blob URLs as tainted, but allows data URIs, which means we're stuck in the middle with these two. In addition, IE9 doesn't support btoa for base 64 encoding, so we'd need to reimplement it ourselves.

[rmccue]

Looks like there's no great way to detect this cross-browser without special casing or triggering security notices, so I'm going to see if we can get the FF bug fixed: ​https://bugzilla.mozilla.org/show_bug.cgi?id=804522

[peterwilsoncc]

I've logged this with the Modernizr team to see if they come up with something: ​https://github.com/Modernizr/Modernizr/issues/1688

[azaozz]

I've tried a different detection approach:

• Add 2 <span style="font-size: 200px;">, one with a "box" character (a valid char that the browser cannot render) and the other with an emoji. The spans should be off-screen, position: absolute; left -1000em; or similar.
• Check the spans widths. If equal, there's no emoji support.

This seems to work well (apart from being dependent on the emoji font having different width for the "box" char). However it has a major flaw: these spans have to be in the body for the browser to render them so we can get the width.

Because of that the emoji detection script cannot run in the head, which is very desirable. There is a workaround: run in the head, append a fake body with the 2 spans, then remove it. However that seems too hacky to add to all WordPress sites.

Wondering if there is a way to "combine" the two methods.

[rmccue]

Replying to azaozz:

• Check the spans widths. If equal, there's no emoji support.

I think this breaks in Chrome with font-weight: 600. Chrome has the correct width for the element, but doesn't actually draw the glyphs.

[rmccue]

Relevant bug report is at ​https://bugzilla.mozilla.org/show_bug.cgi?id=1209480 - regression in FF41 caused by updating the Canvas rendering method.

[peterwilsoncc]

Firefox 46 fixed this, seems safe to close off.

[pento]

Agreed.