Description
The VulnerabilityView and TrackChanges (peer review) WYSIWYG editors serialise code block newlines using different HTML representations. This causes content saved by one editor to render incorrectly in the other — specifically, newlines inside code blocks are lost or broken when content is round-tripped through peer review.
Steps to reproduce
- Navigate to
/portal/VulnerabilityView and add a vulnerability with a multi-line code block in the Details field.
- Submit the assessment for peer review.
- Open peer review and and observe the Details field.
- Add newlines that are missing to reflect Vulnerability View and Add new content on a newline as a mock suggestion.
- Complete the peer review and accept the changes as the assessor.
- Navigate back to
/portal/VulnerabilityView and observe the Details field.
Expected behaviour
- TrackChanges editor should render exactly as they appeared in the VulnerabilityView — newlines inside code blocks preserved
- Accepted peer review changes should render in VulnerabilityView exactly as they appeared in the TrackChanges editor — newlines inside code blocks preserved.
Actual behaviour
- Code block newlines are lost in Peer Review / Vulnerability View
- Inline code items collapse or split unexpectedly.
These details are saved in faction db's Vulnerability Collection
VulnerabilityView saves to DB as:
<div class="toastui-editor-ww-code-block"><pre><code>1\n2\n3</code></pre></div>
<p><code>a b c</code></p>
Rendered as shown in Screenshot # 1
After accepting TrackChanges edits, DB contains:
<pre><code>1<br />2<br />3<br />4</code></pre>
<p><code>a</code></p>
<p><code>b</code></p>
<p><code>c</code></p>
<p><code>d</code></p>
Rendered as shown in Screenshot # 4
Key difference:
- VulnerabilityView uses literal
\n for newlines; TrackChanges uses <br />
Original Details content in VulnerabilityView editor:
Peer review editor showing the same content:
TrackChanges editor after reviewer adds changes:
VulnerabilityView after accepting review — broken rendering:

Description
The VulnerabilityView and TrackChanges (peer review) WYSIWYG editors serialise code block newlines using different HTML representations. This causes content saved by one editor to render incorrectly in the other — specifically, newlines inside code blocks are lost or broken when content is round-tripped through peer review.
Steps to reproduce
/portal/VulnerabilityViewand add a vulnerability with a multi-line code block in the Details field./portal/VulnerabilityViewand observe the Details field.Expected behaviour
Actual behaviour
These details are saved in faction db's Vulnerability Collection
VulnerabilityView saves to DB as:
Rendered as shown in Screenshot # 1
After accepting TrackChanges edits, DB contains:
Rendered as shown in Screenshot # 4
Key difference:
\nfor newlines; TrackChanges uses<br />Original Details content in VulnerabilityView editor:
Peer review editor showing the same content:
TrackChanges editor after reviewer adds changes:
VulnerabilityView after accepting review — broken rendering: