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

 Thank you for the patch, @dmsnell!

 Alright, we need to deal the compatibility bugbear once and for all if we
 want to make a truly informed decision here. I really didn't want to have
 to put in this amount of effort, but let's stop being hand-wavy, dig deep,
 and see what this "compatibility" really gets us.

 First of all, your proposed patch produces a syntax error in both Firefox
 < 40 and Edge < 12 as-is. If we really want this to work there, we'd first
 need to put some more effort in, namely by removing [https://caniuse.com
 /mdn-javascript_grammar_trailing_commas_trailing_commas_in_functions
 trailing commas in function calls]. This is an additional restriction than
 the ones imposed by [https://developer.wordpress.org/coding-standards
 /wordpress-coding-standards/javascript/ the JS style guide], which even
 recommends some ES6 constructs like `class`, but for the sake of argument
 let's go with it and say that we expect contributors to treat this file
 differently.

 I tested this in several scenarios via Browserstack, after removing the
 trailing commas:
 - Firefox 39 on Windows 11: support comes back as false, because
 apparently Windows 11 does not support the UN flag emoji. Every browser
 fails the test in Windows 11.
 - Firefox 39 on Windows 10: Windows 10 seems to support even fewer emoji
 than Windows 11, with other tests also failing. Every browser fails the
 test in Windows 10.
 - Firefox 39 on MacOS Monterey: support comes back as false, even though
 the OS supports all tested emoji (as confirmed by latest Chrome, Safari,
 and Firefox on the same OS). The browser itself is failing us here,
 possibly due to using older, incompatible system calls.
 - Firefox 39 on MacOS Ventura: the browser doesn't open properly, as your
 independent testing had confirmed.

 Edge < 12 will only run in Windows 10, which also doesn't support the UN
 flag emoji (and probably never will, as Microsoft has moved on to Windows
 11, as evidenced by the current Emoji level support disparity). It's not
 available on Browserstack so I wasn't able to test with it, but given the
 other tests we know it won't work correctly anyway due to a lack of OS-
 level support.

 Moving on to mobile OSes, old mobile Firefox versions are not available on
 the Play Store to install, because of API level restrictions. This means
 that there's effectively no plausible way for a regular user to have an
 old Firefox mobile on a modern Android phone. And even if the user were to
 enable sideloading and purposely sideload an old version of Firefox for
 whatever arcane reason, it's doubtful it would work given the changes to
 Android that have taken place in the last 7 years.

 Firefox on iOS, like any other browser, uses the system WebKit engine
 instead, so it'll use a modern engine if running on a modern iOS. Which
 means that it's effectively impossible to have an old browser engine on a
 modern iOS, unless you jailbreak your device, port a browser and its
 engine to iOS, compile the whole thing, and sideload it.

 So, given all of the above, who are we solving things for? Linux users
 running modern system unicode / text libraries but an ancient version of
 Firefox that they compiled themselves (because the package manager version
 is obviously much newer, and because old binaries are almost certainly
 ABI-incompatible)?

 As far as I can tell, after my research and testing, attempting to
 maintain compatibility solves the issue for exactly **zero** users out
 there.

 But moving on to hypotheticals, you could make the argument that this will
 one day help Firefox < 40 users on Windows 11 (once it adds support for
 the UN flag emoji). But then you also need to consider that:
 - The failure mode (once the trailing commas are removed) is to **load an
 unnecessary polyfill without anything breaking**. That's what's happening
 on **every browser** right now because of the bug we're trying to solve.
 It's not ideal from a performance point of view, but it works, and Firefox
 < 40 / Edge < 12 users have much bigger performance issues elsewhere
 anyway. I can't overstate how this is not in any way, shape, or form,
 something we should be caring about.
 - **Core does not support those browsers**, and other things **will**
 fail. `wp-includes` has other scripts that will fail in Firefox < 40, and
 this will only get worse as time goes by.
 - Realistically, how many Firefox < 40 users can there possibly be on
 Windows 11?! That's a 7 year old browser on a 1 year old OS, which is not
 exactly a common use-case.

 As such, my research leads me to conclude that maintaining this level of
 compatibility brings absolutely no benefit in the real world today, that
 it's unlikely to bring any future benefit, and that it's thus merely a
 theoretical concern.

 ----

 So what are our options?

 I'm more than happy for us to use `\uD83C\uDFF3\uFE0F\u200D\u26A7\uFE0F`,
 `\u{1F3F3}\uFE0F\u200D\u26A7\uFE0F`, or
 `\u{1F3F3}\u{FE0F}\u{200D}\u{26A7}\u{FE0F}`; to me it's all the same if
 the current tests use higher code points or surrogate pairs, as long as
 they work.

 However, I don't think we should in any way try to convince contributors
 to put in the effort to learn about higher code points vs surrogate pairs,
 and to convince them to use surrogate pairs as the "better option". Nor to
 espouse a concern with compatibility that has no actual bearing in the
 real world.

 So I'd remove the following entirely:

 {{{
          * Input strings in this function should split supplementary plane
 code points
          * into their constituent UTF-16 code units to avoid browser
 compatability issues.
          * These are code points above U+FFFF. For example, the character
 🅰 is U+1F170,
          * and while on newer browsers we can write that as '\u{1f170}',
 on older browsers
          * we need the code unit sequence '\uD83C\uDD70' instead (Edge <
 12, Firefox < 40).
 }}}

 We might as well remove the trailing commas too, to avoid the syntax error
 that actually breaks things and prevents the polyfill from being loaded in
 older browsers, given that we've identified the issue is there.

 So I'm attaching my proposed patch based on yours, which:
 - maintains your string literals
 - removes the trailing commas
 - removes the aforementioned comment

 I hope this version is consensual, given everything I've outlined in this
 post, but if not, I hereby preemptively agree to any modifications you may
 want, in the interest of landing a fix before either of us becomes
 unavailable for further discussion, due to the quickly-approaching holiday
 season.

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