Bug overview description.
Color DText formatting like this does not display at all in DText box previews. Not only that, using color DText within tables breaks the formatting display in previews, with text surrounded by the color element ([color=#000000][/color]) and the following text within the rest of table cell with the color syntax disappearing in the preview. Closing table tags such as [/tr], [/tbody] and [/table] also appear above tables or within the table's cells in the previews. All the text after the table also disappear in the preview with the exception of additional tables below it.

Color DText formatting also adds line breaks in previews when used within bulleted lists, also causing indents and margins to break for nested lists.

Comments also cannot display any colored DText at all; for example, comment #4625430 had red and cyan colored text when it was initially posted. Now the text is all white (in the standard theme) except for links, although the formatting is still there, as clicking "Respond" in the comment in question adds the quote to the comment box at the bottom with all the initial DText formatting used added to it.

This bug thankfully doesn't affect any other rendered text themselves, only previews and comments.

What part(s) of the site page(s) are affected?
Any text boxes that allow DText formatting and the ability to preview DText. Primarily the wiki but this has also affected comments and the forum.

What is the expected behavior?
The color formatting working properly in previews, including within tables. The preview properly renders as a like how it appears after the edit or post is made.

What actual behavior is given instead?
Please re-read the overview description.

Time of incident (if applicable).
After the site upgrade in March 2020. Admittedly, I did not report on this bug up until this post because I believed that there were more important bugs that had to be taken care of at the time, deciding to report this once the furor over the upgrade itself died down.

Can you reproduce the bug every time?
Yes.

What steps did you take to replicate this bug?
I will point to the worst case of this bug with the howto:sites_and_sources page. The actual page itself is fine, but if you go to the wiki editor for that page and immediately preview it, then you'll see how broken this bug gets.

To test this bug again on the wiki, I went to the transformation page (which uses lazy table formatting instead) and used the editor there. All of the below were tested with the preview function.

• Adding color DText around the first line doesn't break the table below, but no color shows in the preview.
• Adding color DText in the first header doesn't affect anything either, but again there's no color.
• Adding color DText around the title of the section's opening tag causes the title to become [color=colorname. The rest of the text in the line after the closing bracket (i.e. the actual intended title and the closing color tag) are treated as being within the section itself. However, I believe that this is the intended behavior for opening section tags, so I'm not going to be concerned with this.
• Adding color DText around all the text in the first bulleted item (save for the asterisk and first space) added a line break after the bullet and shifted the margin to the right. The table is still fine.
• I've nested the third item in the list (making it a level two bullet) and added the color formatting around the word "wiki". Another line break was added after "No" and before "wiki". The next item below reset the margin back when it maintained its level one bullet (one asterisk). Changing that to level two, three and four bullets reset the margin to those levels.
• Adding color DText formatting in the normally empty first header cell in the table causes the closing tags for the row, the header, and the table ([/tr][/thead]

[/table]) to appear above the table. All of the text underneath the table is missing from the preview.

• I then added the formatting around humanoid in the fourth header cell. The linked word disappeared, but no further closing tags were added above the table.
• I then added the formatting around the first X in the table (row 2, column 2) and it too disappeared. The closing tag for that row and the table body ([/tr][/tbody]) were added to the other closing tags above the table, between [/thead] and

[/table].

• I then added the formatting around the exclamation point in the superscripted "symbol" ^(!A) next to anthro_to_humanoid. Another [/tr] was added to that line of closing tags between the second [/tr] and [/tbody], and all the text within the cell after the opening parenthesis disappeared.
• Finally, I copy-pasted the now heavily-broken table to the bottom of the page's source text. Another table appears in the preview, but all the text between the two tables remain missing. All the broken closing tags from the copied second table appear right next to the original broken closing tags above the first table.
• I've discovered another bug in this very forum post while previewing it. Adding the table closing tag in this bulleted list without using the monospaced text formatting around it causes another line break to be added before the tag and (only in Firefox) the list's margins to be shifted to the left from there. This bug even stays in the rendered text. The margin only resets if a double line break is added after the list (as is typical behavior here).

Errors or other messages returned (if any).
None.