[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 dmsnell):

 > any browser that does not support fromCodePoint also does not support
 Emoji 14

 This is the point I was questioning, actually. While I couldn't get a
 running copy of a browser that doesn't support `fromCodePoint`, I was able
 to get Firefox 75 running (previous versions of Firefox opened as a
 transparent window with no rendering; I think it's an issue with Ventura
 🤷‍♂️. Chrome has been very difficult to get running on older versions).

 In Firefox 75, which was released April 7, 2020, I loaded a test site at
 https://s.xkq.io/unicode.html. This rendered
 [https://s.xkq.io/media/unicode-14.png correctly], handling Emoji added in
 Unicode 14, released on September 14, 2021.

 So I think what's happening is that the browser renders via OS/platform
 support and doesn't have to directly support Unicode updates. Again, this
 may not matter practically for the patch here, but I think it's inaccurate
 to assume that a lack of `String.prototype.fromCodePoint` implies a lack
 of updated Unicode rendering support. To know that we'd have to examine
 the OS release,  or do the rendering trick we already do.

 > everything was indeed a char code and not a code point.

 okay now I see, as I was looking at the patch earlier and not the file.

 https://github.com/WordPress/WordPress/blob/a12598977269f1f78c524d112218196d723cb42e
 /wp-includes/js/wp-emoji-loader.js#L78-L81

 {{{
 isIdentical = emojiSetsRenderIdentically(
     [ 0xD83C, 0xDDFA, 0xD83C, 0xDDF3 ],
     [ 0xD83C, 0xDDFA, 0x200B, 0xD83C, 0xDDF3 ]
 );
 }}}

 Looks like this tracks its lineage back to the
 [https://github.com/WordPress/WordPress/commit/b53b12ff8cf33fb92592d0fc135db53964c68614
 original code]

 Strangely though back when that was introduced it was possible to write
 these as string literals, so I'm not sure why we're passing them in to
 `fromCharCode`. They //are// listed as code units, but fed directly intro
 a string builder, so I think they could be listed as
 `\ud83c\uddfa\d83c\uddf3` without any risk of support issues.

 On that note they would still be appropriately stored as such, because
 there's no way in JavaScript to enter direct code points apart from
 calling something like `fromCodePoint`.

 ---

 On this note, I now wonder what you discovered is wrong about the original
 code, as passing a sequence of code units to `fromCharCode` still properly
 decodes the string in the same way that `fromCodePoint` does, and this a
 result of how JS strings are UTF-16.

 You can see with a simple test.

 {{{
 String.fromCodePoint.apply(null, [0xd83c, 0xdd70]) ===
 String.fromCharCode.apply(null, [0xd83c, 0xdd70]);
 String.… === '🅰'
 }}}

 Does this patch materially change //anything//? I guess I'm still
 fundamentally confused on what's broken and what's fixed.

 ---

 For the purposes of this patch, I wonder if there's a reason to introduce
 another indirection through `fromCodePoint` rather than resorting to
 string literals. Seems like this would be less confusing. Maybe @pento
 knows why this wouldn't work?

 {{{
 emojiSetsRenderIdentically(
     // U+1F1FA U+1F1F3
     // "region indicator U, regional indicator N"
     '\ud83c\uddfa\ud83c\uddf3',
     // U+1F1FA ZWS U+1F1F3
     // "region indicator U, zero-width space, regional indicator N"
     '\ud83c\uddfa\u200b\ud83c\uddf3'
 )
 }}}

 Not only less confusing, but that brings us back to a direct measure of
 whether the browser renders the Emoji as we expect, rather than testing
 that the browser builds the string //and// renders as we expect.

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