This regression was probably introduced in
4f4441fb07 and is caused by the fact that
the variable `isHtml` conflates two different meanings:
- The event contains an HTML message
- The event message is displayed using HTML
This is an important difference. Plain text messages that contain
emojies are rendered with an HTML string and thus have to be sanitized
etc. But they must not use the MarkDown CSS styles for HTML messages.
The MarkDown CSS styles include `whitespace: normal` because HTML events
use `<br/>`-tags for line breaks. Plain text messages with emojies
obviously don't use `<br/>`-tags, so these styles must not be applied.
Signed-off-by: Jonas Schürmann <jonasschuermann@aol.de>
We were still running the emojione regex on all messages to
determine if they were *only* emoji (for the big emoji). This is
pointless on messages that we already know don't have emoji.
Also stop exporting unicodeToImage because it isn't used anywhere.
Emojione has graphics for a lot of the symbol / dingbat characters
which are within the basic multilingual plane, but the new
fast-path regex was only detecthing surrogate pairs, so not
counting the symbols as emoji.
Adding the code code button was done by manipulating the HTML of
the event body to add a span tag, then adding the onclick handler
after the thing was mounted. Apart from splitting the code between
two places, adding the span tag was, according to Chrome's
profiler, taking up quite a lot of CPU cycles (apparently as soon
as you set the innerHTML on a div). Instead, just build the whole
lot together after the component mounts.
Trivial fast-path optimisation: plain text messages cannot possibly contain pre
blocks so there's no point in trying to parse them in order to add code copy
buttons.
Emojione's regex for detecting emoji is *enourmous* and we were
running it on every display name, room name, message etc every time
those components mounted. Add a much simpler regex to rule out the
majority of strings that contain no emoji and fast-path them.
Makes room switching about 10% faster (in my tests with all the
profiling turned on).
We recently updated our version of emojione but this update included the addition of emoji represented in unicode with ZWJ (Zero-Width-Joiners). These ZWJs are not present in the asset file names, so any emoji with ZWJ in them were just not found (404 on the web client).
This updates `unicodeToImage` to be compatible with emojione 2.2.7 so that the correct filenames are used when converting from unicode to <img>.
