AkkomaGang/akkoma

Fork 92

[bug] Upstream tracking issue: Bug in EarmarkParser causes newlines to not show in MFM posts when the post uses html tags #829

New issue

Open

opened 2024-08-18 09:54:01 +00:00 by ilja · 1 comment

ilja commented

2024-08-18 09:54:01 +00:00

Contributor

Your setup

From source

Extra details

No response

Version

3.13.2-616-g90adb3cf (current develop, but with #823 also added)

PostgreSQL version

N/A

What were you trying to do?

See upstream issue https://github.com/RobertDober/earmark_parser/issues/158

In Akkoma this results in the following problem:

Remote instance sends MFM

<center>snoot\nboop</center>

What did you expect to happen?

We expect this to become

<center>snoot<br>boop</center>

What actually happened?

But it actually becomes

<center>snootboop</center>

Running yourself (in Akkoma folder, run iex -S mix or iex -S mix phx.server)

iex(1)> "<center>snoot\nboop</center>" |> Pleroma.Web.CommonAPI.Utils.format_input("text/x.misskeymarkdown")
<no file>:1: warning: Failed to find closing <center>
{"<center>snootboop</center>", [], []}

Logs

No response

Severity

I can manage

Have you searched for this issue?

I have double-checked and have not found this issue mentioned anywhere.

### Your setup From source ### Extra details _No response_ ### Version 3.13.2-616-g90adb3cf (current develop, but with #823 also added) ### PostgreSQL version N/A ### What were you trying to do? See upstream issue <https://github.com/RobertDober/earmark_parser/issues/158> In Akkoma this results in the following problem: Remote instance sends MFM ``` <center>snoot\nboop</center> ``` ### What did you expect to happen? We expect this to become ``` <center>snoot<br>boop</center> ``` ### What actually happened? But it actually becomes ``` <center>snootboop</center> ``` Running yourself (in Akkoma folder, run `iex -S mix` or `iex -S mix phx.server`) ``` iex(1)> "<center>snoot\nboop</center>" |> Pleroma.Web.CommonAPI.Utils.format_input("text/x.misskeymarkdown") <no file>:1: warning: Failed to find closing <center> {"<center>snootboop</center>", [], []} ``` ### Logs _No response_ ### Severity I can manage ### Have you searched for this issue? - [x] I have double-checked and have not found this issue mentioned anywhere.

ilja added the

bug

label 2024-08-18 09:54:01 +00:00

ilja referenced this issue from AkkomaGang/akkoma-fe

2024-08-18 09:55:37 +00:00

Use FEP-c16b: Formatting MFM functions #410

ilja changed title from ~~[bug] upstream tracking issue: MFM Bug in EarmarkParser causes newlines to not show in MFM posts when the post uses html tags~~ to [bug] Upstream tracking issue: Bug in EarmarkParser causes newlines to not show in MFM posts when the post uses html tags

2024-08-18 09:56:56 +00:00

ilja commented

2024-08-19 15:21:18 +00:00

Author

Contributor

It's documented behaviour, but they do want this behaviour so a fix may come eventually. Tags need to be in their own line. See https://daringfireball.net/projects/markdown/syntax#html

Since they need to be on their own line, I was thinking of maybe working around this problem by first prettifying the html for MFM (for Markdown this isn't needed because we don't re-parse and therefor it doesn't matter that different instances have different behaviour), but it just gives other problems like changing preceding spaces. Generally speaking, preceding spaces don't matter, but they do matter for us.

# Two extra spaces bc the prettifier wants to add two extra spaces for indentation
iex(1)> "<center>snoot\nboop</center>" |> Floki.parse_fragment!() |> Floki.raw_html(pretty: true) |>  Pleroma.Formatter.markdown_to_html(%{breaks: true}) 
"<center>  snoot\nboop</center>"

iex(2)> "<center>      snoot\nboop</center>" |> Floki.parse_fragment!() |> Floki.raw_html(pretty: true) |>  Pleroma.Formatter.markdown_to_html(%{breaks: true})
"<center>  snoot\nboop</center>"

Maybe we could figure something out ourselves, but then it starts to become very hacky for something which I already consider a work-around.

I'll keep the issue open, but I fear the real fix will be to get better HTML content from all *key software (which is not something we control).

It's documented behaviour, but they do want this behaviour so a fix may come eventually. Tags need to be in their own line. See <https://daringfireball.net/projects/markdown/syntax#html> Since they need to be on their own line, I was thinking of maybe working around this problem by first prettifying the html for MFM (for Markdown this isn't needed because we don't re-parse and therefor it doesn't matter that different instances have different behaviour), but it just gives other problems like changing preceding spaces. Generally speaking, preceding spaces don't matter, but they do matter for us. ```iex # Two extra spaces bc the prettifier wants to add two extra spaces for indentation iex(1)> "<center>snoot\nboop</center>" |> Floki.parse_fragment!() |> Floki.raw_html(pretty: true) |> Pleroma.Formatter.markdown_to_html(%{breaks: true}) "<center> snoot\nboop</center>" iex(2)> "<center> snoot\nboop</center>" |> Floki.parse_fragment!() |> Floki.raw_html(pretty: true) |> Pleroma.Formatter.markdown_to_html(%{breaks: true}) "<center> snoot\nboop</center>" ``` Maybe we could figure something out ourselves, but then it starts to become very hacky for something which I already consider a work-around. I'll keep the issue open, but I fear the real fix will be to get better HTML content from all *key software (which is not something we control).

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: AkkomaGang/akkoma#829

No description provided.