Line breaks not displaying in details section of alert details page

[john-f-chamberlain]

Describe the Bug:
The details section of an alert displays the details text with line breaks stripped.

Steps to Reproduce:

1. Send an alert with a multi-line message in the "details" field
2. Visit the alert details page

Expected Behavior:
The details section should have multiple lines

Observed Behavior:
The details section displays all of the text on one line.

Screenshots/Stack Traces:
GoAlert Interface:

Pushover:

Application Version:
v0.31.1

Additional Context:
It appears that GoAlert is just not converting line breaks (\n) into HTML <br> tags.

[mastercactapus]

Details are processed as markdown text, of which the default behavior is to join subsequent lines unless there is a blank line separating.

I agree this is a bit confusing, especially because details are often sent as text without markdown processing. Testing it here on GitHub, it seems single-line breaks are also preserved.

@Forfold any idea if the markdown library we use has an option for this?

[john-f-chamberlain]

The weird thing is that if you look in page source, the line breaks are preserved, just not converted from \n to <br> so definitely some weird behavior from the md library. Though it should be fairly easy to do a search/replace for \n to <br> after the fact since the \n are still there.

[Forfold]

Looks like we can use https://github.com/remarkjs/remark-breaks as a plugin to remarkjs/react-markdown

However:

When should I use this?
This plugin is useful if you want to display user content closer to how it was authored, because when a user includes a line ending, it’ll show as such. GitHub does this in a few places (comments, issues, PRs, and releases), but it’s not semantic according to HTML and not compliant to markdown. Markdown already has two ways to include hard breaks, namely trailing spaces and escapes (note that ␠ represents a normal space):

lorem␠␠
ipsum

lorem\
ipsum

Both will turn into <br>s. If you control who authors content or can document how markdown works, it’s recommended to use escapes instead.

[mastercactapus]

In our case, it's warranted -- since details are communicated in messages as rendered markdown and unrendered text -- it makes sense to keep them closer together.

Plus, not all inputs to alerts are aware/capable of providing markdown anyway, so many alerts are just raw text when they come in. IMO that plugin makes a lot of sense for the UI.