Steps to reproduce
- Create a new note, with a list whose contents span two or more screenfuls, and whose items’ texts are unique enough to tell where you are in the list at a glance (e.g. using numbers). Optionally, Include some picture or video embeds in the list, as this will make the problem glaringly obvious.
- Switch to preview mode, then split right so there are two panes
- Scroll the first pane down such that the list is partly off-screen at the top, making note of the exact item visible at the top of the screen. (For easiest visibility, scroll such that an image or video embed is partly off the top of the screen.)
- Open a new tab in the second pane
Did you follow the troubleshooting guide? [Y/N]
Yes
Expected result
No change to the scroll position of the list in the first pane
Actual result
The scroll position jumps such that the same item no longer appears in that exact position (usually going off-screen entirely). The jump is usually only a few source lines, but can be huge if the source line in question is a picture or video. (Depending on the exact scroll position, it is possible for the jump not to occur, but a randomly chosen position will trigger it about 90% of the time, and nearly 100% of the time when a partially-displayed image or video is at the top of the viewport.)
Once the scroll position has jumped, further opening or closing tabs in the second pane has no effect, unless you scroll back to the previous position or to another position in the first pane. But you can continuously reproduce the effect by doing so (i.e. scrolling somewhere then opening, closing, or switching tabs in the other pane).
Environment
SYSTEM INFO:
Obsidian version: v1.3.5
Installer version: v1.2.8
Operating system: Windows 10 Pro 10.0.19045
Login status: logged in
Catalyst license: supporter
Insider build toggle: off
Live preview: on
Legacy editor: off
Base theme: light
Community theme: none
Snippets enabled: 0
Restricted mode: on
RECOMMENDATIONS:
none
Additional information
The issue is caused by MarkdownPreviewView.onResize() asking its renderer to perform an unnecessary scroll in response to the resize event triggered by the workspace.onLayoutChange() called when opening or closing tabs, changing the active tab or opening files in those tabs.
This Hover Editor monkeypatch illustrates a possible fix: changing the onResize() method to check if the scroll position it’s going to set is the same as the renderer’s already-set scroll position. In my testing, this stops the bug from occurring but does not appear to negatively impact actual resizing of the window or its panes.
Additional background discussion can be found here: Discord