Don't consider textual characters to be emoji

[robintown]

We were using emojibase-regex to match emoji within messages. However, the docs state that this regex matches both emoji and text presentation characters. This is not what we want, and will result in false positives for characters like '↔' that could turn into an emoji if paired with a variation selector. Unfortunately, none of the other regexes provided by Emojibase do what we want either (milesj/emojibase#174). In the meantime, browser support for the RGI_Emoji character sequence class has made it feasible to write an emoji regex by hand, so that's what I've done.

Depends on element-hq/element-web#27674

[t3chguy]

Do you have any info about browser compat for RGI_Emoji and the various unicode versions that maps to?

[t3chguy]

Answering myself: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Regular_expressions/Unicode_character_class_escape

[robintown]

Yes, and the other important compatibility table to look at is the one for v mode: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/RegExp/unicodeSets

[robintown]

Technically https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/RegExp/unicodeSets is okay by our support policy, but this change will cause the application to completely fail to load on browsers from early 2023. If we care about that, we could instead have the emoji regex simply degrade to a regex that matches nothing. Opinions?

[t3chguy]

this change will cause the application to completely fail to load on browsers from early 2023.

We really must catch it via Modernizr/similar, we should never blank screen, we must show the incompatible browser view.

[t3chguy]

Looks sane otherwise