Plugin breaks non-editable Rich Text formatting

[AndreiDaydream]

The plugin doesn't play nice with TMP rich text formatting, such as "Hello <color=red>World"

Say I have that text in an input field (rich text enabled, rich text editing not enabled). Trying to edit anything in that field with this plugin active messes things completely, from jumping the cursor around to editing the < > formatting and breaking it - likely due to passing that format back and forth between web and unity and breaking it along the way.

It would be fine if copy-paste ignored the formatting and just worked with the visible text, I just want it to not break editing the input field manually.

Steps to Reproduce:

• Createa TMP_InputField with Rich Text enabled, and Rich Text editing disabled
• Via code, populate it with some < > tags to write Hello <color=red>World</color>
• Test it in editor: type text in that field, at the start, middle, end; notice the desired behavior
• Build it on web
• Test the input field again: notice that typing in text in that field will jump your cursor around and break the rich text formatting

Desired Behaviour:

• Keep same behaviour in editor as web build (do not break formatting when typing, do not change cursor position)
• It is acceptable to ignore formatting when copy-pasting, work with the visible text only. Just don't break it

[hyunwoo9120]

Hi @AndreiDaydream,
Could you tell me which versions of Unity and TMP you're using?
I'm currently using Unity 2022.3.xx and TextMeshPro 3.0.9, but I can't find the Rich Text Editing option.

I’ve fixed an issue related to the cursor.
However, since I wasn’t able to verify it across all input cases and Unity/TMP versions, there may be some unintended side effects. 😿

[AndreiDaydream]

Thanks for the quick response :)
Using Unity 6.2. TMP is no longer a package it seems, it's just built into the editor?

But this is a feature of the InputField component, not the Text component, which I believe is what your image depicts.

- at the very bottom

[hyunwoo9120]

As you already know, WebGLInput works in a one-to-one relationship with the HTML input element.
While we see formatted text in Unity, the actual HTML input contains something like hello<color=red>world.
If you delete a character before the “w”, it will actually remove the “>”, which breaks the formatting.
So as you mentioned, this issue seems to be deeply related to the caret position — the visual position and the internal position are different.

It might take some time to fix this properly, but for now, how about adding a checkbox option to enable Rich Text Editing = true when modifying text in your project as a workaround?

[AndreiDaydream]

Yes, I understand why the issue happens, and I can see how this isn't easy to fix.

The workaround may work for some scenarios, but it changes the behaviour, and in my case, that is worse than just disabling copy-paste for the field, which is what I'm going with for now. If this becomes critical I might try a solution myself, but for now it's not a top priority.

For the record, as I said, I think an acceptable fix is to just ignore everything between < > when manually handling the text.
Even if "deleting the character before w" sets my text to "world" (deleted nothing, and removed my formatting) that is better than messing with the formatting - maybe it can do that based on the InputField's rich text formatting field itself.
In my case, which is basically a mini-IDE, I can just parse the text and re-format it again. But the problem is the plugin breaks the formatting - I'd rather it just deleted it instead, if that makes sense.

[mariommoreno]

I'm using for implementing Emojis, but in webGL (the only platform I'm using) the rich text gets exposed when deleting first or last char (< pressing "Delete" or > pressing "Backspace").
In this case, it would be a good solution to delete the whole tag if "Allow rich text editing" is disabled.