The Bug
When editing a sign that uses e.g. a custom color, or other formatting like bold or italic text, when editing such a sign, the formatting is preserved when saving, but the preview renders it without the formatting
The changelog of 23w14a also states "Signs with non-text chat components can no longer be edited", tho it's not quite clear if this refers to signs with any kind of formatting not being supposed to be editable, or if it just means that signs that have a different string-source like a translate element are excluded.
Reproduction
/setblock ~ ~ ~ minecraft:warped_sign{front_text:{messages:['{"text":"test","bold":true,"color":"#8eedeb"}','{"text":"test","color":"#8eedeb"}','{"text":"test","italic":true,"color":"#8eedeb"}','{"text":"test","obfuscated":true,"color":"#8eedeb"}']}}Right click the sign
-> ❌ The text shows in black without formattingEdit some text
Click done
-> ✔ Text shows with formatting again
Observed Result
While editing the sign, the preview does not show the formatting, and any edited line will show unformatted on the actual sign while the dialog is still open.
For bold formatting, it is also possible to add more text than fits the sign.
After confirming with "Done", the correct formatting is applied again.
Expected Result
Either:The sign always shows the correct formatting;
Or: it's impossible to edit such a sign.
Attachments
Comments 6
@unknown Do you have a source for that? I only looked at https://www.minecraft.net/en-us/article/minecraft-snapshot-23w14a, which states "Signs with non-text chat components can no longer be edited", and doesn't say anything about "specially formatted".
(edit)
Hmm now that I think about it, I guess that could be interpreted as "signs that have any kind of formatting other than text", I interpreted it as "other text sources like translate-elements are impossible to edit".
That's the line I was referring to. "color" "bold" etc. all are non-text fields in the chat component format, so it seems expected that it prevents editing.
The current implementation is non-text text-determining fields (translate, selector, nbt), and click events preventing editing,which follows the second interpretation from your comment, with the exception of the click events.
Don't think excluding selector, nbt, or score would be necessary, as they are evaluated on a sign. The only one that isn't evaluated is translate.
E.g. /data modify block -26 3 7 front_text.messages[0] set value '{"selector":"@p"}' will be evaluated as text and still be editable.
Also intrestingly, clickEvents do not seem to prevent editing explicitly, just running a command takes priority over editing. Using a selector as shown above will put a clickEvent of type suggest_command on the sign, and since that doesn't do anything on a sign (but still can be defined), you can edit the sign.
Tested on 1.20.4 and 24w05b.
/setblock ~ ~ ~ oak_sign{front_text:{messages:['{"translate":"gui.cancel"}','{"text":""}','{"text":""}','{"text":""}']}} replaceis not editable, as expected. But adding another element like
/setblock ~ ~ ~ oak_sign{front_text:{messages:['[{"text":" "},{"translate":"gui.cancel"}]','{"text":""}','{"text":""}','{"text":""}']}} replacemakes it editable, which seems unintended, as editing breaks the translation part.
As it somehow has not been mentioned here yet, this bug leads to a rather nasty side effect that malicious servers can exploit. Servers can send a sign edit GUI that contains translation or keybind formatting, which the client will resolve and send back to the server in plain text. This can be used to get the player's language, keybindings, and detect mods that include custom keybinds or translation texts.
This issue can also be exploited within the anvil as well by sending an item with such a formatting for a name, which the client will resolve and update within the anvil output slot.
Worst of all is that the server can also immediately close such a GUI, such that the client will never see it appear visually.
Here is a (now unmaintained) mod that seeks to fix this issue: https://github.com/JustAlittleWolf/ModDetectionPreventer
Seems like editing should be impossible, seeing as any other non-text objects prevent editing too (such as translate, selector, clickEvent, etc.); it was even stated in a changelog that "specially formatted signs" wouldn't be editable anymore.