thunder-app/thunder

Fix spoiler formatting edge cases

Closed this issue · 5 comments

Bug Description

Some edge cases for marking spoilers:

  1. When a spoiler is marked without whitespace after ::: it is ignored by Thunder
  2. When a spoiler is not terminated by ::: on a new line some content is not shown completely and some seems to show up after the spoiler ends
  3. Spoilers without terminating ::: are not stacked into each other (this is likely an improvement rather than a scope of this bug)

Expected Behaviour

Spoilers are rendered as collapsible blocks

Steps to Reproduce

  1. Add spoiler by using default Lemmy UI template
  2. Remove whitespace between ::: and spoiler
  3. Optionally remove newlines except for the first newline after the title

Additional Context

Lemmy UI is used as a reference implementation for spoiler rendering, this is a post with most of edge-cases used: https://programming.dev/post/10803689

This issue may require a clarification from Lemmy UI team on how spoilers are implemented as that seems to be de-facto standard implementation.

App Version

0.2.9

Device

Pixel 8 Pro

OS

Android 14 build 5.15.110-android14-11-gcc48824eebe8-ab10865596

Thanks for the report!

When a spoiler is marked without whitespace after ::: it is ignored by Thunder

This should be an easy case to solve by adjusting the regex for spoilers.

When a spoiler is not terminated by ::: on a new line some content is not shown completely and some seems to show up after the spoiler ends

This one will be a bit more tricky to solve, but should be manageable. Right now, the spoiler logic explicitly checks for ::: in a new line.

Spoilers without terminating ::: are not stacked into each other (this is likely an improvement rather than a scope of this bug)

Do you mean nested spoilers? If so, then this might be the trickiest to solve. We can create a separate issue for this since this would be more of an enhancement as you mentioned!

Edit: the code block below is not correct because it has an extra ::: (see my second comment for how the parsing seems to work)

i.e.,

::: spoiler title

text in main spoiler

::: spoiler nested spoiler
some text inside nested spoiler
:::

:::

Alright, so I did some testing on spoilers and how they behave on Lemmy and I think I have a pretty good understanding

The following syntaxes work as expected (they create one spoiler tag)

::: spoiler spoiler
Hello!
:::
:::spoiler spoiler with no whitespace
Hello!
:::

Here's where we run into some weird edge cases:

  1. Lemmy doesn't need an ::: ending in order to display the spoiler. If ::: is not present, it will assume the spoiler continues until the end:
::: spoiler a
::: spoiler a
text
  1. Lemmy will create nested spoilers if there is an additional ::: spoiler within the first spoiler:
::: spoiler a
text
::: spoiler b
more text
  1. If there is an ending :::, Lemmy will consume the first instance of ::: only if ::: is on a new line with no other text (and up to 3 white spaces)
::: spoiler a
text
::: spoiler b
more text (no whitespaces before :::)
:::
::: spoiler a
text (1 whitespaces before :::)
 :::
::: spoiler a
text (2 whitespaces before :::)
  :::
::: spoiler a
text (3 whitespaces before :::)
   :::
  1. The following examples will show the ::: within the spoiler (and cause the spoilers to be nested since it could not find a valid ::: ending
::: spoiler a
text (4 whitespaces before :::)
    :::
::: spoiler a
text:::
::: spoiler a
text :::
::: spoiler a
text
a:::

Thank you for your research 🙇

It looks like in case of repeated spoilers without a closing ::: lemmy-ui will close all of them at once with the first encountered closing :::

I.e. a block like this:

::: spoiler outer 
First level

::: spoiler middle
Second level

::: spoiler inner
Third level
:::

Not a spoiler

Will produce three levels of nested spoilers and the rest of the text will not be a spoiler. Not sure if that's intended, really

It looks like in case of repeated spoilers without a closing ::: lemmy-ui will close all of them at once with the first encountered closing :::

I believe I captured that behaviour as well in the PR!

Hooray, everything works in 0.3.0-2

Thank you ❤️