Scrolled preview pane with fenced code is partially blank after repositioning in split

Steps to reproduce

  1. Open two different notes in adjacent panes. (e.g. by opening the help vault and unlinking the panes)
  2. In one pane, create a large amount of text that includes a ```-fenced code block (or navigate to the “Format Your Notes” page in the help vault)
  3. Ensure the pane is in preview mode, active, and scroll to the bottom of the note
  4. Drag the pane so it is before or after the other pane, keeping the current split direction

Expected result

The moved pane should continue to be displayed (preferably at the same scroll position). If it was the active pane, it should remain active.

Actual result

The moved pane is partly or fully blank, and no longer active, with the scrollbar positioned at the top. Scrolling it restores the missing content.


  • Operating system: Windows
  • Obsidian version: 0.10.9

Additional information

It seems to only be a problem when there’s a fenced code block in the page. The amount of content that disappears seems dependent on how far down you scroll. It doesn’t seem to happen if the pane changes parents (i.e. you move from a horizontal split to a vertical one or vice versa, or drag out of the current parent altogether).

It appears the reason it works when the split direction is changed, is because the pane is being resized and triggering an update of the virtual display. Calling the moved leaf’s onResize() method works around the problem, but it’s not clear why it’s a problem in the first place, i.e.

  • Why is the scroll repositioning in the first place?
  • What does having fenced code have to do with it?

Answering those questions is above my current level of reverse-engineering skill. :wink:

Sounds like a bug indeed. I think I know how to get it fixed.

Why is the scroll repositioning in the first place?

I think it might be because moving the DOM element out messes with scrollTop (resetting it?) but only under some conditions in the rendering engine.

What does having fenced code have to do with it?

Fenced code might be causing the conditions in the rendering engine. That’s my guess at least.

I have a fix for the blank page issue but I haven’t been able to prevent the DOM change from scrolling to the top sadly. I think the only fix would be to store the scroll position and restoring it after, which is a bit more complexity than I’d like for now.