Study Comments - Unicode Emoji behavior for specific emojis.

[Nolan5G]

Exact URL of where the bug happened

https://lichess.org/study/k3J6NU76/VewJOhs8

Steps to reproduce the bug

This exact process doesn't happen every time, but it appears to be related to Unicode Variation Selectors (U+FE0F) breaking in conjunction with specific codes.

1. Copy and paste into a study comment for a particular move a Unicode Emoji that has a decomposition of more than one code.
   e.g. ◻️ which is white medium square and the variation selector provided.

The Unicode Explorer link which displays the characteristics of this specific emoji.

https://unicode-explorer.com/emoji/white-medium-square

2. Typically these decomposable emojis work when you paste them as a comment in a brand new study.

3. However over time, the issue arises whenever one of these emojis are undone (via CTRL+Z) and then repasted in. It might be a prequisite to step 3 that a chess piece unicode character is used as well.

What did you expect to happen?

An example of the Comment Form correctly taking a unicode emoji and it being saved correctly in the output Study component.

What happened instead?

Something like this happens every time it attempts to set the comment:

Here is what the input study__comment form shows:

Operating system

Windows 11

Browser and version (or alternate access method)

Firefox Developer Edition - 135.0b9

Additional information

This started probably 1/2 a year or 1/4 of a year ago in 2024.
I thought it was an aberration since it never happened before.

Before submitting this issue, I tried doing a Github code search in the lila repository to see if I could spot the bug.
To the best of my code reading abilities (I'm a C# / SQL developer), I didn't spot anything obviously intentional that would leave it out.

Code Analysis

1. ui/analyse/src/study/commentForm.ts

I was mostly interested in the doSubmit function. It appeared the study.makeChange("setComment") was the entry point for saving the form data.

2. ui/analyse/src/study/studyCtrl.ts

I'm not too familiar with where the makeChange function was sending the data to.
I assumed .send() was some sort of messaging to decouple components - the question for me is where?

Luckily I found a corresponding setComment function in the handlers for the Study control.
There I found that the control's tree had a setCommentAt function!

3. ui/tree/src/tree.ts

We find our function, and it appears to override an existing text if one exists, otherwise it pushes a new comment.

This isn't it.

I have a feeling that this actually gets handled when it gets rendered. So I'm searching for the interrupt and comment instead now, since my previous search failed me.

4. ui/analyse/src/treeView/common.ts

I like what I'm seeing here in the renderComment definition.

A Tree.Comment type is a start!

I don't understand the truncatedComment muhc.

The part that interested me was innerHTML - and I'm not too disappointed as it leads me to:

5. ui/common/src/richText.ts

The definition for innerHTML is interesting. It uses a VNode - something I know nothing about, but I assume it's a virtual node.
I also see the word cachedA and something resembling a caching system. I have no idea what that system is.

It appears that VNode and the Hooks it uses are from snabbdom

6. ui/common/src/richText.ts

Here is where my journey ends.

I don't know TypeScript, and I'm certainly awful at figuring out Web programming.

The best I can tell is that the HTML cleanup looks ok. I'm still spooked by the caching - it's probably what causes this issue to be persisted for me as a user.