(updated title to more accurately reflect findings after additional troubleshooting, see further down in the thread for more accurate description of behavior)
Original bug report follows this line
Steps to reproduce
While working in a long note (Note A) in edit mode, use Cmd+Shift+Click to open a link to Note B in a new pane.
Expected result
Note B opens in the new pane and the cursor position in the still-open Note A does not change.
Actual result
Note B opens correctly, but the cursor in Note A moves to the end of Note A or to the beginning of Note A.
This behavior is not consistent. Currently while working in a note (Note A) it is happening each time I Cmd+Shift+Click a link in edit mode, and each time it is moving the cursor to the end of Note A immediately after opening Note B in the new pane. A few days ago while working in another long note the cursor would move to the top of the note.
When the cursor moves it scrolls the screen to the top/bottom and I have to scroll back to my original position. This is frustrating when working with multiple notes from an outline for example.
Again, this doesn’t happen all the time, but seems to happen more often than not on longer notes. The current note is 2,227 words.
Specifically in this declaration in the CSS snippet:
.cm-hmd-list-indent .cm-tab, ul ul { position: relative; }
When I comment that one line out the behavior returns to normal.
However… When I turn the Minimal theme back on the behavior then goes back to the buggy behavior described above, even with the above CSS snippet line commented out. Turning Minimal theme back off returns to the expected correct behavior.
Clearly there is some sort of interplay between styles happening here but I don’t know how a CSS style could so drastically alter the scroll position of the preview window when it is rendered.
Even weirder… I just stumbled onto the fact that toggling between edit and preview modes changes behavior depending on whether or not there is a heading (#) at or near the top line. If there is an h1 or h2 (and maybe others) on the top line or within 2-4 lines of the top line it toggles to the correct location (i.e. doesn’t scroll to the top of the file when toggling preview mode on). But if I scroll just one more line (so the heading is now 5 lines from the top) and then toggle preview mode then the preview mode renders as if I was looking at the start of the file, effectively scrolling all the way to the top. Then when I toggle back to edit mode it jumps right back to the position I was in.
This turned out not to be consistent either. See below.
This is two minutes long because I wanted to scroll around and trigger the behavior in multiple areas within the document.
What I found is that it appears even more random than I previously thought, since in this case I found instances where even with a heading at the top it still jumped to a random position higher in the doc when toggling preview mode.
In the recording I made the scrollbar large and yellow so it is more obvious what is happening.
@WhiteNoise Got it, my bad I had found the problem with everything deactivated but had reactivated some during my experiments just prior to that screencast.
Here is a new recording. All plugins and custom CSS are disabled, and the theme is set to None.
The behavior still occurs. I walk through it step by step in the recording, showing the CSS snippet and turning it on and off during the recording showing the difference in behavior.
Note the behavior varies depending on where the scroll position is. I discovered while making the screencasts that once a sub-bullet is the top-most line in edit mode, triggering preview mode causes it to jump immediately to the top of the document when the preview is rendered, then back when edit mode is triggered again. This may not be the only time it occurs but it was the most dramatic so I used it for the screencast. Note also that the movement varies in some cases even when the scroll is changed only by a tiny amount. (one click turn of my mouse scroll wheel)
Also apologies for being a bit rambling in my prior posts, this is just an extremely frustrating bug because it was occurring seemingly at random, and I still don’t know if there are other cases where it may occur.
I just checked and confirmed there is a line in the Minimal theme (line 1681) that causes the same behavior.
body.minimal-rel-preview .markdown-preview-view ul ul {
position:relative;
}
It is triggered the same way – scroll far down the doc and place a sub-bullet on the top line then trigger preview mode causes Obsidian to render preview mode at the top of the doc instead of in the expected position, exactly as shown in the screencast.
This is why it was still being activated when I had the Minimal theme in place in the first screencast.
Another finding: bug also occurs if a quoted line is at the top of the pane when triggering preview mode.
For example, toggling preview mode when the top of the pane looks like this works as expected:
However scrolling down just a couple of clicks on the mouse wheel to this point results in the bug being triggered when toggling preview mode: (yes this is a very subtle difference, look at the spacing between the title and first displayed line)
Good sleuthing @davecan, I was experiencing the same issue and this post helped me figure out that it was caused by position: relative; in my custom CSS.
I have a similar problem. I tend to read my long notes along with a linked preview pane. And they are almost never in sync (they are perfectly synced only in case of short note [read 20 lines]).
The preview pane shifts back to the top of the page while I am scrolling the edit window. And I need to manually scroll preview window back to the line I was reading/editing.
And it happens all the time when its a long note (might have images too) with or without plugins/themes. I am at version 0.12.5
I am not sure if I need to open a new bug request here (@WhiteNoise).
@davecan and @luckman212, can you please check if you face the same thing (edit and preview windows split)?
@DummyME? It happens all the time? This bug report is limited to some triggers. Open a new bug report and post screen recordings? No themes, no css and no third party plugins.
Same issue
Installer Version: 0.12.10
Current Version: 13.23
Only happens when i horizontally split a pane. When I open the second one, it resets the first one, when i close the second pane, it again resets the first one lol.