Callout blocks rendered as single-character-wide column of text while editing

[mtnliving]

Steps to reproduce

Note: This bug is not easily reproducible and seems to be somewhat erratic in its occurrence. There does seem to be a pattern to it, however, described below.

Note also in this description that the “Strict line breaks” Editor Display option is OFF.

1. Create a callout block: quote, note, etc. and enter a string/block of text. It doesn’t matter if this is done in Live Preview or Source mode.
2. Click away from the callout block. In Live Preview mode, this will render the block per the style directives.
3. Open another markdown note, then return to the note with the callout block you just created. Click into the callout block to edit it. The string of text will sometimes be rendered as a single column of text, right justified, one letter per line for the entire length of the string of text. This happens both in Source mode and Live Preview mode, and ONLY seems to occur if there is no space character after the last character in the string of text.
4. Adding one or more space characters after the callout block seems to alleviate the rendering error.

Did you follow the troubleshooting guide? Y

Expected result

Callout blocks of text should render as a contiguous block of text instead of a single column of individual characters.

Actual result

Callout blocks of text sometimes render as a single column of right-justified text, one character per line.

Environment

SYSTEM INFO:
Obsidian version: v1.9.13
Installer version: v1.8.9
Operating system: Darwin Kernel Version 25.0.0: Mon Aug 25 21:17:54 PDT 2025; root:xnu-12377.1.9~3/RELEASE_ARM64_T6041 25.0.0
Login status: logged in
Language: en
Catalyst license: supporter
Insider build toggle: on
Live preview: on
Base theme: adapt to system
Community theme: none
Snippets enabled: 0
Restricted mode: on

RECOMMENDATIONS:
none

---

Additional information

See screenshot

[WhiteNoise]

I have never seen this thing. I’ll keep the BR open a for while.
Let me know if you find reproducible steps in the sandbox vault. Thanks

[Iuk34]

I can confirm I’m experiencing the same issue. It happens regularly in edit mode, though not every time—it seems more frequent when first opening a file.

To make the bug disappear, I need to place the cursor on the first line of the callout. The bug is cross-platform: I’ve observed it on both Android and Linux Mint.

As suggested to me on Discord, this might be related to the > not being placed in front of each text block within the callout. However, in my case, it’s actually the opposite—each text block does have a > in front of it.

[WhiteNoise]

can you provide a source document where this happens in the sandbox vault?

Thanks

[andanteinblue]

I run into this problem quite often too, mainly on the desktop, also when it is the last thing in the note, with no trailing space. Here is a screenshot of a problematic entry in restricted mode, with no snippets and default theme:

Interestingly the distortion remains while in source mode

If I exit Obsidian and restart, the problem goes away, but it returns if I delete text after the callout and enter more text into the callout.

[ariehen]

Untitled.md (348 Bytes)

[WhiteNoise]

thank you for providing a reproducible example finally!

[Kemall]

Steps to reproduce

1. Create or open a note where a Markdown table is the very last element (no blank lines after the table).

2. View the note in Reading view or Live Preview — everything renders correctly.

3. Switch to Source mode.

4. The bottom portion of the note breaks: text is rendered as a vertical single-character column on the right side of the editor.

Did you follow the troubleshooting guide? Y

Expected result

Switching to Source mode should render the note correctly regardless of whether a table is the last element in the file.

Actual result

When switching to Source mode, the text near the bottom of the note becomes vertically stacked — each character appears

on its own line in a narrow column on the right side of the editor, making the content completely unreadable. See the attached screenshots.

Workaround that confirms the cause: If I switch back to Reading view, add a blank line after the table, then close and reopen the note, Source mode renders correctly again. However, simply adding the blank line and switching to Source mode within the same session does not fix it — the note must be closed and reopened.

Environment

• OS: Windows

• Community plugins: None (I don’t use any community plugins)

• Duration: I have been experiencing this bug for approximately one year across multiple Obsidian updates.

Additional information

The bug is 100% reproducible on any note where a Markdown table is the final element. The issue is purely visual — the underlying file content is not corrupted. I am attaching two screenshots:

• Screenshot 1: Source mode showing the broken rendering — characters stacked vertically on the right side.

  

• Screenshot 2: The same section in Reading view, rendering correctly.

  

[WhiteNoise]

I can’t reproduce. You didn’t provide the output of show debug info.
Also there is not table any of your screenshots.

[Kemall]

Hi, sorry for the confusion. I mistakenly used the word ‘table’. I actually meant ‘Callouts’ (like > [!warning] or > [!tip]). The visual glitch happens when a Callout is the very last element in the note.

Here is the output of my debug info:

SYSTEM INFO:
Obsidian version: 1.12.7
Installer version: 1.8.10
Operating system: Windows 11 Home 10.0.26200
Login status: logged in
Language: en
Catalyst license: none
Insider build toggle: off
Live preview: on
Base theme: light
Community theme: none
Snippets enabled: 0
Restricted mode: on

RECOMMENDATIONS:
none

[ariehen]

On mobile at the moment so can’t throughly test, but I can repro. No new lines after the callout.

> [!note]
> The Duke and Duchess of Sussex have arrived in Australia for a four-day tour which will see them combine visits to

---

I changed table to callout in the topic title.

---

UPDATE: Had a look on Windows. Seems it still happens even with a newline or text after the callout.

source mode | live preview

[Kemall]

Yes, that’s true. However, since you’ve now added something at the end, the issue should disappear when you close and reopen the note.

[ariehen]

@Kemall

the issue should disappear when you close and reopen the note

Thanks for the reminder. I initially read that yesterday when I tested on mobile, but didn’t try that when I quickly checked on Windows earlier.

[Lupo]

Disclaimer: AI-drafted, verified by me before filing. I answer follow-ups.

Deterministic repro, sandbox vault, 1.13.4, no plugins, default theme. Note whose last line is inside a callout, no newline after it:

paragraph before

> [!note]
> - a long list item, long enough to wrap in the editor pane, a long list item, long enough to wrap in the editor pane, a long list item, long enough to wrap in the editor pane

Live Preview, cursor on “paragraph before” (callout renders as widget), then click into the callout. The last line renders one character per row. Same in Source mode. Plain > text last lines are affected too.

The line carries style="text-indent:-Npx; padding-inline-start:Npx" with N equal to the editor content width. That is the hanging-indent line decoration with a wrong width.

Cause, from app.js (the view plugin with indentCache / updateDomInternal): it walks the .cm-line children of .cm-content and maps each to a line with view.posAtDOM(el). When the document ends with a block widget, CodeMirror keeps an empty trailing .cm-line after it; posAtDOM on that element returns doc.length, inside the widget’s replaced range, so lineAt() is the callout’s last line. coordsAtPos(from + prefixLength) for a position hidden in the widget returns the widget’s right edge, and that width is stored in indentCache for the line number. Checked in the sandbox: posAtDOM(trailingLine) === doc.length, indentCache.get(4).size === cm-content width.

The cache is keyed by line number and cleared only on CSS change or file reopen. A note that ended inside a callout at any moment while writing keeps the bad entry after lines are added below; editing the affected line re-measures it. That matches the reports above: last element, no trailing newline, gone on reopen, back after deleting text below the callout.

[RyzenFromFire]

I am also experiencing this issue. Also not easy to reproduce, and I originally thought it was due to themes or plugins, but I was able to reproduce in the sandbox vault as follows:

• Create a callout of any type.
• Input any text content with length longer than the full editor width (i.e., type more than one line of text).
• Ensure there are no blank lines or text after the callout.
• Click on the callout itself or directly below it.

If there is any content whatsoever after the content (i.e., anything other than the end of the file) the bug will not appear:

Test environment: Windows 11, Obsidian 1.13.7, Live Preview, plain sandbox vault. Was also able to reproduce in the sandbox vault on Linux (Arch/EndeavourOS, also Obsidian 1.13.7), so it’s definitely not exclusive to Windows.

Notable points:

• The bug does not require a table to be the last content in the callout, nor any form of list (as I initially thought).
• The bug does not require no trailing space on the text content inside the callout, but does seem to require there to be no blank lines after the callout, and seems to be triggerable by clicking on the “blank line after the callout” in which a cursor briefly shows after clicking (before showing the callout content glitched as shown in screenshots from previous reports), despite such a line not existing.
  • As mentioned in Kemall’s post about the callout being the very last element.

It is also quite difficult to get any debug information about the issue, since it requires you to basically be actively editing/selecting the callout, so you can’t just use the inspect element tool, but from my troubleshooting, the point about the indent width being set to the full content width from Lupo’s report indeed seems to be the cause.

For now, the most feasible workaround seems to be to just make sure your files have a newline or something at the end.