All the bugs listed in this post are found in 5.0.0-beta71-rc13 with detailed chat and the RTE enabled.
I consolidated them all in this post as they are pretty insignificant on their own but are all part of the same chat subsystem.
Text messages after system messages are misaligned. The users’ avatar is drawn partly over the system message.
see: [Bug] TS3 server chat - TeamSpeak Client - TeamSpeak (already approved and forwarded)
Nearly all Markdown flavors agree on this. You can denote a fenced code block using three backticks (
```) or three tildes (
~~~) above and below the code on a single line each.
In TeamSpeak, those markers can be proceeded by anything else, so turns into , which is simply wrong.
Most other parsers simply interpret this as inline code.
Inline Code is automatically syntactically highlighted. This makes absolutely no sense as there is no way to disable this as a sender the same way there is with an entire code block. When sending inline code it can be assumed that even if it is real code the snippet is too short to infer the language from it. So instead of getting a nice monospace gray in gray inline code, you get a rainbow-colored mess that you have no control over. Point in case:
TeamSpeak - again - supports Markdown features that don’t exist and no one asked for.
Again most Markdown flavors and parsers handle this the same way. Inline code is inline.
Newlines are replaced with spaces and empty lines break the inline code segment.
Not so in TeamSpeak. Here inline code can be everything as long as it starts and ends with a backtick.
This can be really annoying when deliberately passing text with line breaks between backticks.
When sending a broken link to embedded content like YouTube in spoiler tags, the message appears to be empty.
The latest version tries to embed shorts but fails to parse the URL and instead of finding the video ID inserts
false to the embed. When inspecting the regex used to extract the video ID I found that the one you used is well established in the community but somewhat dated.
Instead, you can use this one:
const vidID = e.match(/^.*(?:youtu.be\/|v\/|e\/|u\/\w+\/|embed\/|clip\/|shorts\/|v=)([^#\&\?]*).*/);
It uses non-capturing groups, so there is no longer a need to dynamically find the correct capture group. This also supports clips. In testing, I found that URLs to YouTube clips are not recognized as attachments but with this regex should work the same as all other videos.
When selecting multiple messages a click anywhere on the selection bar will reset the selection.
In Markdown you can escape backticks in inline code by using double backticks to mark the code segment. This is correctly parsed when displaying a message.
Unfortunately, the RTE struggles with this:
When typing `a`Space you suddenly get an empty code block. Thus when trying to type text with inline code suddenly stuff goes missing.
Here are all the sequences I found with this behavior:
Similar behavior shows when typing ```a```Space or ~~~a~~~Space. Here a new code block appears from the last three backticks / tildes leaving the previous part behind.
This happens when trying to clean up after the previous bug. After removing the wrongly created code block you can no longer use backspace before moving the cursor. Not even writing new stuff helps.
Code blocks are not parsed correctly when editing messages. Point in case:
You can also create this state when writing by specifying a language for the highlighter.
When pasting emojis from other sources things go wrong.
Mainly they are not replaced as intended with the twemoji equivalent.
Secondly, when inserting emojis using the Windows emojis picker, they are inserted twice.
When tagging a contact, the tag is in no way highlighted.
One of the tags is an actual tag, while the other one is just text.
When spamming Escape because the editor broke again, the message you meticulously crafter for an entire hour while trying not to trigger one of the many bugs in the RTE just disappears. This happened to me so often, that I often resort to tying messages longer than three words in Notepad and then pasting them to still get an approximation of what I will send.
A virtual scroller for the emoji picker is IMHO stupid - at least the way it is implemented now. When scrolling through the emojis quickly they load far too slowly. This behavior is toleratable for dynamic content like chat messages, but for static content, where the user usually has some reference in mind to find the emoji they are looking for, it is unacceptable to see a blank container because the picker is “loading”. If you really want to use the full SVGs in the picker, rasterize them when first opening the emoji picker and store them in volatile memory to avoid loading time when showing them again.
This is all I could find / remember ad hoc.
For now, I will sadly turn off the RTE until significant improvements are made so it doesn’t destroy itself.