WordPress.org

Make WordPress Core

Opened 4 years ago

Closed 3 years ago

#34049 closed defect (bug) (wontfix)

Emoji detection is broken on FF41, OS X 10.10

Reported by: rmccue Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: Emoji Keywords:
Focuses: javascript Cc:

Description

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.

Change History (10)

#1 @rmccue
4 years ago

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.

#2 @rmccue
4 years ago

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)

#3 @rmccue
4 years ago

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.

Last edited 4 years ago by rmccue (previous) (diff)

#4 @rmccue
4 years ago

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

#5 @peterwilsoncc
4 years ago

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

#6 follow-up: @azaozz
4 years ago

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.

Last edited 4 years ago by azaozz (previous) (diff)

#7 in reply to: ↑ 6 @rmccue
4 years ago

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.

#8 @rmccue
4 years ago

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

#9 @peterwilsoncc
3 years ago

  • Component changed from General to Emoji
  • Focuses javascript added
  • Keywords close added

Firefox 46 fixed this, seems safe to close off.

#10 @pento
3 years ago

  • Keywords close removed
  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Status changed from new to closed

Agreed.

Note: See TracTickets for help on using tickets.