[spoiler] does not support emoji

Spoilers and emoji do not work correctly together.

Examples:


Input:
[spoiler]:+1:[/spoiler]

Output:

:+1:

Expected Output:

+1


(even the manually constructed expected result appears to have issues here. expected results are as one would expect, spoilered text on either side of an emoji)

Input:
[spoiler]prefix text :+1: Suffix text[/spoiler]

Output:

prefix text :+1: Suffix text

Expected Output:

prefix text +1 Suffix text

5 Likes

If the tag doesn’t work for emoji’s why would you expect it to work inside tags that also include an emoji. How is this a bug? It’s simply not supported with emoji’s right now.

i’m having trouble parsing this, why would this not be a bug? Okay so emoji aren’t supported in spoiler, that turns my first example into a feature request, but the second example has to be a bug. Look at my second example:

[spoiler]prefix text <img src="/images/emoji/emoji_one/+1.png?v=0" title=":+1:" width="20" height="20" class="emoji" alt="+1"> Suffix text[/spoiler]

this produces bad output where the manually placed emoji is spoilered, but the text is not, even though it is clearly marked to be spoilered in the markup:

prefix text +1 Suffix text

or an example that doesn’t use an emoji:

[spoiler]prefix text <img src="//assets-meta-cdck-prod-meta.s3.dualstack.us-west-1.amazonaws.com/original/3X/2/4/245f54ed160ca0a7315e55e66f50ffda001ba9f9.png" title="discourse"> Suffix text[/spoiler]

prefix text Suffix text

Clearly spoilers work for images, and they work for text, but they do not work for text and images, regardless of the source of the images. That is a bug.

3 Likes

Maybe I’m missing something, but you seem to have shown 3 entirely different situations, and somehow related them into one bug.

The last result is not the same as the first two, and a regular link to an image, not an emoji code which usually produces an emoji.

My point was that if there was an issue with the first result, you should definitely expect there to be an issue with the second result. I don’t see why anyone would expect there to be a bad result in the first, yet the second to work out.

It seems like a feature request to me, but if it’s a bug so be it.

But there are’t three different situations. there are at most two. To clarify:

we have scenario 1a which is a constructed minimal reproduction of the primary reported bug/feature request, namely that the emoji parser is not working inside of [spoiler] tags

[spoiler]:+1:[/spoiler]

scenario 1b is a reproduction of the discovering scenario, where the emoji was embedded in a larger block of text

[spoiler]prefix text :+1: Suffix text[/spoiler]

These two scenarios are the same issue: namely that the :+1: emoji code was not parsed when inside [spoiler] tags.

when constructing the expected results for the bug report another issue, that is likely related to the parsing code that determines spoilers, was discovered. This is arguably an different bug but is noted here because it causes the expected results of the second case to display incorrectly.

This Scenario 1b expected results was created by pasting the HTML for the :+1: emoji from the emoji_one emoji set in place of the :+1; emoji code in the spoiler.

[spoiler]prefix text <img src="/images/emoji/emoji_one/+1.png?v=0" title=":+1:" width="20" height="20" class="emoji" alt="+1"> Suffix text[/spoiler]

a second example of the separate but likely related issue was generated in my first reply to you:

[spoiler]prefix text <img src="//assets-meta-cdck-prod-meta.s3.dualstack.us-west-1.amazonaws.com/original/3X/2/4/245f54ed160ca0a7315e55e66f50ffda001ba9f9.png" title="discourse"> Suffix text[/spoiler]

3 Likes

Fair enough, I’ll defer this tissue to the judgment of people who better understand ruby/rails. I’m glad you made it clear that there’s at least two different things being described now.

It is actually a javascript thing as ‘cooking’ of posts done in the js dialect library.

1 Like

This should be fixed by:
https://github.com/discourse/discourse-spoiler-alert/pull/12

5 Likes