[wp-trac] [WordPress Trac] #57301: Emoji feature detection is incorrect

[WordPress Trac]

#57301: Emoji feature detection is incorrect
---------------------------+--------------------------------------
 Reporter:  sergiomdgomes  |       Owner:  (none)
     Type:  defect (bug)   |      Status:  new
 Priority:  normal         |   Milestone:  Awaiting Review
Component:  Emoji          |     Version:  trunk
 Severity:  normal         |  Resolution:
 Keywords:                 |     Focuses:  javascript, performance
---------------------------+--------------------------------------

Comment (by sergiomdgomes):

 Replying to [comment:3 dmsnell]:
 > Is this a valid assumption? Or maybe I should ask, what are we referring
 to when we say "latest emoji"?

 In this case, we're referring to Emoji 14, which is what the current
 version of Twemoji in use in `wp-emoji` (Twemoji 14.0.2) polyfills, and
 that the current tests check for.

 I think the statement **is** 100% correct, which is to say that any
 browser that does **not** support `fromCodePoint` also does **not**
 support Emoji 14, but the impact of getting this wrong is minimal, in that
 we only add an unnecessary polyfill. Which is what's currently happening
 on every browser anyway.

 > if, for instance, we used "\ud83c\udd70" as [0xd83c, 0xdd70].map( c =>
 String.fromCharCode(c) ).join('') instead of [0x1f170].map( c =>
 String.fromCodePoint(c) ).join('') then we'd get the same result even
 though we might assert it's not there (because fromCodePoint isn't).

 I imagine that our current set of tests isn't perfect, yes, even if they
 do use a canvas to actually render things and compare the rendered result.
 But again, the impact is low if we get it wrong; we just harmlessly
 polyfill something we don't need to.

 > You had me at arrays of numbers but lost me with "hexadecimal" numbers.

 Sorry, you're right that it isn't particularly detailed; the goal was
 merely to help reviewers easily scan for them visually in the existing
 code. I meant that they're numbers that just happen to be recorded as hex
 literals.

 The issue that the PR fixes arises from the confusion around what these
 hex literals represent; char codes vs code points.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/57301#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform